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SYSTEM, METHOD AND ARTICLE OF MANUFACTURE FOR 
SOFTWARE-DESIGNED INTERNET RECONFIGURABLE HARDWARE 

5 RELATED APPLICATIONS 

This application claims priority from Provisional U.S. Patent Application entitled 
System, Method, and Article of Manufacture for a User Literface for Transferring 
Configuration Information for a Configuring a Device in Reconfigurable Logic, serial 
10 number 60/219,753, filed July 20, 2000, and which is incorporated herein by reference 
for all purposes. 

FIELD OF THE INVENTION 

15 

The present invention relates to reconfigurable logic devices and more particularly to 
network-based configuratiomn of a logic device. 

20 BACKGROUND OF THE INVENTION 

It is well known that software-controlled machines provide great flexibility in that they 
can be adapted to many different desired purposes by the use of suitable software. As 
well as being used in the familiar general purpose computers, software-controlled 
25 processors are now used in many products such as cars, telephones and other domestic 
products, where they are known as embedded systems. 

However, for a given a function, a software-controlled processor is usually slower than 
hardware dedicated to that fimction, A way of overcoming this problem is to use a 
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special software-controlled processor such as a RISC processor which can be made to 
function more quickly for limited purposes by having its parameters (for instance size, 
instruction set etc.) tailored to the desired functionality. 

5 Where hardware is used, though, although it increases the speed of operation, it lacks 
flexibility and, for instance, although it may be suitable for the task for which it was 
designed it may not be suitable for a modified version of that task which is desired 
later. It is now possible to form the hardware on reconfigurable logic circuits, such as 
Field Programmable Gate Arrays (FPGA's) which are logic circuits which can be 

10 repeatedly reconfigured in different ways. Thus they provide the speed advantages of 
dedicated hardware, with some degree of flexibihty for later updating or multiple 
functionality. 

In general, though, it can be seen that designers face a problem in finding the right 
15 balance between speed and generality. They can build versatile chips which will be 
software controlled and thus perform many different functions relatively slowly, or 
they can devise application-specific chips that do only a limited set of tasks but do them 
much more quickly. 

20 A compromise solution to these problems can be foimd in systems which combine both 
dedicated hardware and also software. The hardware is dedicated to particular 
functions, e.g. those requiring speed, and the software can perform the remaining 
functions. The design of such systems is known as hardware-software codesign. 

25 Within the design process, the designer must decide, for a target system with a desired 
functionahty, which functions are to be performed in hardware and which in software. 
This is known as partitioning the design. Although such systems can be highly 
effective, the designer must be familiar with both software and hardware design. It 
would be advantageous if such systems could be designed by people who have 
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familiarity only with software and which could utiUze the flexibility of configurable 
logic resources. Further, it would be advantageous to implement into such systems an 
intuitive, ergonomic interface for selecting and transferring configuration data. 
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SUMMARY OF INVENTION 

A system, method and article of manufacture are provided for network-based 
5 configuration of a programmable logic device. A default application is initiated on a 
programmable logic device. A file request for configuration data fi-om the logic device 
is sent to a server located remotely from the logic device utilizing a network. The 
configuration data is received from the network server, and can be in the form of a 
bitfile. The configuration data is used to configure the logic device to run a second 
10 application. The second application is run on the logic device. 

According to one embodiment of the present invention, the logic device includes one or 
more Field Programmable Gate Arrays (FPGAs). Preferably, a first FPGA receives the 
configuration data and uses that data to configure a second FPGA. The first and second 
1 5 FPGAs can be clocked at different speeds. 

According to another embodiment of the present invention, the defauh application and 
the second appUcation are both able to run simultaneously on the logic device. The 
logic device can further include a display screen, a touch screen, an audio chip, an 
20 Ethernet device, a parallel port, a serial port, a RAM bank, a non-volatile memory, 
and/or other hardware components. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The invention will be better understood when consideration is given to the following 
detailed description thereof Such description makes reference to the annexed drawings 
5 wherein; 

Figure 1 is a schematic diagram of a hardware implementation of one embodiment of 
the present invention; 

10 Figure 2 is a flow diagram of a process for providing an interface for transferring 
configuration data to a reconfigurable logic device; 

Figure 3 depicts a display according to an exemplary embodiment of the present 
invention; 

15 

Figure 4 illustrates an illustrative procedure for initiating a reconfigurable logic device 
according to the illustrative embodiment of Figure 3; 

Figure 5 depicts a process for using a reconfigurable logic device to place a call over the 
20 Internet according to the illustrative embodiment of Figure 3; 

Figure 6 illustrates a process for answering a call over the hitemet; 

Figure 7 depicts a configuration screen for setting various parameters of telephony 
25 fimctions according to the illustrative embodiment of Figure 3; 

Figure 8A depicts an illustrative screen displayed upon receonfiguration of a 
reconfigurable logic device according to the illustrative embodiment of Figure 3; 
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Figure 8B depicts a process for providing a hardware-based reconfigurable multimedia 
device; 

Figure 9 is a diagrammatic overview of a board of the resource management device 
5 according to an illustrative embodiment of the present invention; 

Figure 10 depicts a JTAG chain for the board of Figure 9; 

Figure 11 shows a structure of a Parallel Port Data Transmission System according to 
1 0 an embodiment of the present invention; 

Figure 12 is a flowchart that shows the typical series of procedure calls when receiving 
data; 

15 Figure 13 is a flow diagram depicting the typical series of procedure calls when 
transmitting data; 

Figure 14 is a flow diagram illustrating several processes running in parallel; 

20 Figure 15 is a block diagram of an FPGA device according to an exemplary 
embodiment of the present invention; 

Figure 16 is a flowchart of a process for network-based configuration of a 
programmable logic device; 

25 

Figure 17 illustrates a process for remote altering of a configuration of a hardware 
device; and 

Figure 18 illustrates a process for processing data and controlling peripheral hardware. 

30 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

A preferred embodiment of a system in accordance with the present invention is 
5 preferably practiced in the context of a personal computer such as an IBM compatible 
personal computer, Apple Macintosh computer or UNIX based workstation. A 
representative hardware environment is depicted in Figure 1, which illustrates a typical 
hardware configuration of a workstation in accordance with a preferred embodiment 
having a central processing unit 110, such as a microprocessor, and a number of other 

10 units interconnected via a system bus 112. The workstation shown in Figure 1 includes 
a Random Access Memory (RAM) 114, Read Only Memory (ROM) 116, an I/O 
adapter 118 for connecting peripheral devices such as disk storage units 120 to the bus 
112, a user interface adapter 122 for connecting a keyboard 124, a mouse 126, a speaker 
128, a microphone 132, and/or other user interface devices such as a touch screen (not 

15 shown) to the bus 112, communication adapter 134 for connecting the workstation to a 
communication network (e.g., a data processing network) and a display adapter 136 for 
connecting the bus 112 to a display device 138. The workstation also includes a Field 
Programmable Gate Array (FPGA) 140 with a complete or a portion of an operating 
system thereon such as the Microsoft Windows NT or Windows/98 Operating System 

20 (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating system. Those 
skilled in the art will appreciate that the present invention may also be implemented on 
platforms and operating systems other than those mentioned. 

A preferred embodiment is written using JAVA, C, and the C++ language and utilizes 
25 object oriented programming methodology. Object oriented programming (OOP) has 
become increasingly used to develop complex applications. As OOP moves toward the 
mainstream of software design and development, various software solutions require 
adaptation to make use of the benefits of OOP. A need exists for these principles of 
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OOP to be applied to a messaging interface of an electronic messaging system such that 
a set of OOP classes and objects for the messaging interface can be provided. 

OOP is a process of developing computer software using objects, including the steps of 
5 analyzing the problem, designing the system, and constructing the program. An object 
is a software package that contains both data and a collection of related structures and 
procedures. Since it contains both data and a collection of structures and procedures, it 
can be visuahzed as a self-sufficient component that does not require other additional 
structures, procedures or data to perform its specific task. OOP, therefore, views a 
10 computer program as a collection of largely autonomous components, called objects, 
each of which is responsible for a specific task. This concept of packaging data, 
structures, and procedures together in one component or module is called encapsulation. 

hi general, OOP components are reusable software modules which present an interface 
15 that conforms to an object model and which are accessed at run-time through a 

component integration architecture. A component integration architecture is a set of 
architecture mechanisms which allow software modules in different process spaces to 
utihze each others capabilities or functions. This is generally done by assuming a 
common component object model on which to build the architecture. It is worthwhile 
20 to differentiate between an object and a class of objects at this point. An object is a 
single instance of the class of objects, which is often just called a class. A class of 
objects can be viewed as a blueprint, fi^om which many objects can be formed. 

OOP allows the programmer to create an object that is a part of another object. For 
25 example, the object representing a piston engine is said to have a composition- 
relationship with the object representing a piston, hi reahty, a piston engine comprises 
a piston, valves and many other components; the fact that a piston is an element of a 
piston engine can be logically and semantically represented in OOP by two objects. 
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OOP also allows creation of an object that "depends from" another object. If there are 
two objects, one representing a piston engine and the other representing a piston engine 
wherein the piston is made of ceramic, then the relationship between the two objects is 
not that of composition. A ceramic piston engine does not make up a piston engine. 

5 Rather it is merely one kind of piston engine that has one more limitation than the 
piston engine; its piston is made of ceramic. In this case, the object representing the 
ceramic piston engine is called a derived object, and it inherits all of the aspects of the 
object representing the piston engine and adds further Hmitation or detail to it. The 
object representing the ceramic piston engine "depends from" the object representing 

10 the piston engine. The relationship between these objects is called inheritance. 

When the object or class representing the ceramic piston engine inherits all of the 
aspects of the objects representing the piston engine, it inherits the thermal 
characteristics of a standard piston defined in the piston engine class. However, the 

15 ceramic piston engine object overrides these ceramic specific thermal characteristics, 
which are typically different from those associated with a metal piston. It skips over the 
original and uses new fimctions related to ceramic pistons. Different kinds of piston 
engines have different characteristics, but may have the same underlying ftmctions 
associated with it (e.g., how many pistons in the engine, ignition sequences, lubrication, 

20 etc.). To access each of these fimctions in any piston engine object, a programmer 

would call the same fimctions with the same names, but each type of piston engine may 
have different/overriding implementations of fimctions behind the same name. This 
ability to hide different implementations of a function behind the same name is called 
polymorphism and it greatly simplifies communication among objects. 

25 

With the concepts of composition-relationship, encapsulation, inheritance and 
polymorphism, an object can represent just about anything in the real world. In fact, 
one's logical perception of the reahty is the only limit on determining the kinds of 
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things that can become objects in object-oriented software. Some typical categories are 
as follows: 

• Objects can represent physical objects, such as automobiles in a traffic-flow 
simulation, electrical components in a circuit-design program, countries in an 

5 economics model, or aircraft in an air-traffic-control system. 

• Objects can represent elements of the computer-user environment such as 
windows, menus or graphics objects. 

• An object can represent an inventory, such as a personnel file or a table of the 
latitudes and longitudes of cities. 

10 • An object can represent user-defined data types such as time, angles, and 
complex numbers, or points on the plane. 

With this enormous capability of an object to represent just about any logically 
separable matters, OOP allows the software developer to design and implement a 
15 computer program that is a model of some aspects of reality, whether that reality is a 
physical entity, a process, a system, or a composition of matter. Since the object can 
represent anything, the software developer can create an object which can be used as a 
component in a larger software project in the future. 

20 If 90% of a new OOP software program consists of proven, existing components made 
from preexisting reusable objects, then only the remaining 10% of the new software 
project has to be written and tested firom scratch. Since 90% already came from an 
inventory of extensively tested reusable objects, the potential domain fi'om which an 
error could originate is 10% of the program. As a result, OOP enables software 

25 developers to build objects out of other, previously built objects. 

This process closely resembles complex machinery being built out of assembhes and 
sub-assembhes. OOP technology, therefore, makes software engineering more like 
hardware engineering in that software is built from existing components, which are 
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available to the developer as objects. All this adds up to an improved quality of the 
software as well as an increased speed of its development. 

Programming languages are beginning to fiiUy support the OOP principles, such as 
5 encapsulation, inheritance, polymorphism, and composition-relationship. With the 
advent of the C++ language, many commercial software developers have embraced 
OOP. C-H- is an OOP language that offers a fast, machine-executable code. 
Furthermore, C++ is suitable for both commercial-application and systems- 
programming projects. For now, C++ appears to be the most popular choice among 
10 many OOP programmers, but there is a host of other OOP languages, such as Smalltalk, 
Common Lisp Object System (CLOS), and Eiffel. Additionally, OOP capabilities are 
being added to more traditional popular computer programming languages such as 
Pascal. 

15 The benefits of object classes can be summarized, as follows: 

• Objects and their corresponding classes break down complex programming 
problems into many smaller, simpler problems. 

• Encapsulation enforces data abstraction through the organization of data into 
small, independent objects that can communicate with each other. 

20 Encapsulation protects the data in an object from accidental damage, but allows 

other objects to interact with that data by calling the object's member ftinctions 
and structures. 

• Subclassing and inheritance make it possible to extend and modify objects 
through deriving new kinds of objects from the standard classes available in the 

25 system. Thus, new capabilities are created without having to start from scratch. 

• Polymorphism and multiple inheritance make it possible for different 
programmers to mix and match characteristics of many different classes and 
create specialized objects that can still work with related objects in predictable 
ways. 
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► Class hierarchies and containment hierarchies provide a flexible mechanism for 
modeling real-world objects and the relationships among them. 

> Libraries of reusable classes are useful in many situations, but they also have 
some limitations. For example: 

* Complexity. In a complex system, the class hierarchies for related classes can 
become extremely confusing, with many dozens or even hundreds of classes. 

* Flow of control. A program written with the aid of class libraries is still 
responsible for the flow of control (i.e., it must control the interactions among 
all the objects created from a particular library). The programmer has to decide 
which functions to call at what times for which kinds of objects. 

* Duplication of effort. Although class libraries allow programmers to use and 
reuse many small pieces of code, each programmer puts those pieces together in 
a different way. Two different programmers can use the same set of class 
libraries to write two programs that do exactly the same thing but whose internal 
structure (i.e., design) may be quite different, depending on hundreds of small 
decisions each programmer makes along the way. Inevitably, similar pieces of 
code end up doing similar things in slightly different ways and do not work as 
well together as they should. 

Class libraries are very flexible. As programs grow more complex, more programmers 
are forced to reinvent basic solutions to basic problems over and over again. A 
relatively new extension of the class library concept is to have a framework of class 
libraries. This framework is more complex and consists of significant collections of 
collaborating classes that capture both the small scale patterns and major mechanisms 
that implement the common requirements and design in a specific application domain. 
They were first developed to free application programmers from the chores involved in 
displaying menus, windows, dialog boxes, and other standard user interface elements 
for personal computers. 
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Frameworks also represent a change in the way programmers think about the interaction 
between the code they write and code written by others. In the early days of procedural 
programming, the programmer called Ubraries provided by the operating system to 
perform certain tasks, but basically the program executed down the page from start to 
5 finish, and the programmer was solely responsible for the flow of control. This was 
appropriate for printing out paychecks, calculating a mathematical table, or solving 
other problems with a program that executed in just one way. 

The development of graphical user interfaces began to turn this procedural 
10 programming arrangement inside out. These interfaces allow the user, rather than 
program logic, to drive the program and decide when certain actions should be 
performed. Today, most personal computer software accomplishes this by means of an 
event loop which monitors the mouse, keyboard, and other sources of external events 
and calls the appropriate parts of the programmer's code according to actions that the 
15 user performs. The programmer no longer determines the order in which events occur. 
Instead, a program is divided into separate pieces that are called at unpredictable times 
and in an unpredictable order. By relinquishing control in this way to users, the 
developer creates a program that is much easier to use. Nevertheless, individual pieces 
of the program written by the developer still call libraries provided by the operating 
20 system to accomplish certain tasks, and the programmer must still determine the flow of 
control within each piece after it's called by the event loop. Application code still "sits 
on top of the system. 

Even event loop programs require programmers to write a lot of code that should not 
25 need to be written separately for every apphcation. The concept of an application 
framework carries the event loop concept fiirther. Instead of dealing with all the nuts 
and bolts of constructing basic menus, windows, and dialog boxes and then making 
these things all work together, programmers using apphcation frameworks start with 
working application code and basic user interface elements in place. Subsequently, they 
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build from there by replacing some of the generic capabihties of the framework with the 
specific capabihties of the intended appUcation. 

Apphcation frameworks reduce the total amount of code that a programmer has to write 
5 from scratch. However, because the framework is really a generic apphcation that 
displays windows, supports copy and paste, and so on, the programmer can also 
relinquish control to a greater degree than event loop programs permit. The framework 
code takes care of almost all event handling and flow of control, and the programmer's 
code is called only when the framework needs it (e.g., to create or manipulate a 
1 0 proprietary data structure). 

A programmer writing a framework program not only relinquishes control to the user 
(as is also true for event loop programs), but also relinquishes the detailed flow of 
control within the program to the framework. This approach allows the creation of 
15 more complex systems that work together in interesting ways, as opposed to isolated 
programs, having custom code, being created over and over again for similar problems. 

Thus, as is explained above, a framework basically is a collection of cooperating classes 
that make up a reusable design solution for a given problem domain. It typically 
20 includes objects that provide default behavior (e.g., for menus and windows), and 
programmers use it by inheriting some of that default behavior and overriding other 
behavior so that the framework calls apphcation code at the appropriate times. 

There are three main differences between frameworks and class libraries: 
25 • Behavior versus protocol. Class libraries are essentially collections of behaviors 
that you can call when you want those individual behaviors in your program. A 
framework, on the other hand, provides not only behavior but also the protocol 
or set of rules that govern the ways in which behaviors can be combined. 
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including rules for what a programmer is supposed to provide versus what the 
framework provides. 

• Call versus override. With a class library, the code the programmer instantiates 
objects and calls their member functions. It's possible to instantiate and call 

5 objects in the same way with a framework (i.e., to treat the framework as a class 

library), but to take full advantage of a framework's reusable design, a 
programmer typically writes code that overrides and is called by the framework. 
The framework manages the flow of control among its objects. Writing a 
program involves dividing responsibilities among the various pieces of software 

10 that are called by the framework rather than specifying how the different pieces 

should work together. 

• Implementation versus design. With class libraries, programmers reuse only 
implementations, whereas with frameworks, they reuse design, A framework 
embodies the way a family of related programs or pieces of software work. It 

15 represents a generic design solution that can be adapted to a variety of specific 

problems in a given domain. For example, a single framework can embody the 
way a user interface works, even though two different user interfaces created 
with the same framework might solve quite different interface problems. 

20 Thus, through the development of frameworks for solutions to various problems and 
programming tasks, significant reductions in the design and development effort for 
software can be achieved. A preferred embodiment of the invention utilizes HyperText 
Markup Language (HTML) to implement documents on the Internet together with a 
general-purpose secure communication protocol for a transport medium between the 

25 chent and the Newco. HTTP or other protocols could be readily substituted for HTML 
without undue experimentation. Information on these products is available in T. 
Bemers-Lee, D. Connoly, "RFC 1866: Hypertext Markup Language - 2.0" (Nov. 1995); 
and R. Fielding, H, Frystyk, T. Bemers-Lee, J. Gettys and J.C. Mogul, "Hypertext 
Transfer Protocol HTTP/1.1: HTTP Working Group hitemet Draft" (May 2, 1996). 
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HTML is a simple data format used to create hypertext documents that are portable 
from one platform to another. HTML documents are SGML documents with generic 
semantics that are appropriate for representing information from a wide range of 
domains. HTML has been in use by the World-Wide Web global information initiative 
5 since 1990. HTML is an application of ISO Standard 8879; 1986 Information 
Processing Text and Office Systems; Standard Generalized Markup Language 
(SGML). 

To date, Web development tools have been limited in their ability to create dynamic 
10 Web applications which span from client to server and interoperate with existing 

computing resources. Until recently, HTML has been the dominant technology used in 
development of Web-based solutions. However, HTML has proven to be inadequate in 
the following areas: 

• Poor performance; 

1 5 • Restricted user interface capabilities; 

• Can only produce static Web pages; 

• Lack of interoperability with existing apphcations and data; and 

• Inability to scale. 



20 Sun Microsystem's Java language solves many of the client-side problems by: 

• Improving performance on the client side; 

• Enabling the creation of dynamic, real-time Web applications; and 

• Providing the ability to create a wide variety of user interface components. 



25 With Java, developers can create robust User Interface (UI) components. Custom 

"widgets" (e.g., real-time stock tickers, animated icons, etc.) can be created, and chent- 
side performance is improved. Unlike HTML, Java supports the notion of cUent-side 
validation, offloading appropriate processing onto the client for improved performance. 
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Dynamic, real-time Web pages can be created. Using the above-mentioned custom UI 
components, dynamic Web pages can also be created. 



Sun's Java language has emerged as an industry-recognized language for "programming 
5 the Internet." Sun defines Java as: "a simple, object-oriented, distributed, interpreted, 
robust, secure, architecture-neutral, portable, high-performance, multithreaded, 
dynamic, buzzword-compliant, general-purpose programming language. Java supports 
programming for the Internet in the form of platform-independent Java applets." Java 
applets are small, specialized applications that comply with Sun's Java Application 

10 Programming Interface (API) allowing developers to add "interactive content" to Web 
documents (e.g., simple animations, page adormnents, basic games, etc.). Applets 
execute within a Java-compatible browser (e.g., Netscape Navigator) by copying code 
from the server to client. From a language standpoint, Java's core feature set is based on 
C++. Sim's Java literature states that Java is basically, "C++ with extensions from 

15 Objective C for more dynamic method resolution." 



Another technology that provides similar ftinction to JAVA is provided by Microsoft 
and ActiveX Technologies, to give developers and Web designers wherewithal to build 
dynamic content for the Internet and personal computers. ActiveX includes tools for 

20 developing animation, 3-D virtual reality, video and other multimedia content. The 
tools use Internet standards, work on multiple platforms, and are being supported by 
over 100 companies. The group's building blocks are called ActiveX Controls, small, 
fast components that enable developers to embed parts of software in hypertext markup 
language (HTML) pages. ActiveX Controls work with a variety of programming 

25 languages including Microsoft Visual C++, Borland Delphi, Microsoft Visual Basic 
programming system and, in the future, Microsoft's development tool for Java, code 
named "Jakarta." ActiveX Technologies also includes ActiveX Server Framework, 
allowing developers to create server applications. One of ordinary skill in the art 
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readily recognizes that ActiveX could be substituted for JAVA without undue 
experimentation to practice the invention. 

A preferred embodiment is written using Handel-C, a programming language developed 
5 from Handel. Handel was a programming language designed for compilation into 

custom synchronous hardware, which was first described in "Compiling occam into 

FPGAs", Ian Page and Wayne Luk in "FPGAs" Eds. Will Moore and Wayne Luk, pp 

271-283, Abingdon EE & CS Books, 1991, which are herein incorporated by reference. 

Handel was later given a C-like syntax (described in "Advanced Silicon Prototyping in 
10 a Reconfigurable Environment", M. Aubury, I. Page, D. Plunkett, M. Sauer and J . Saul, 

Proceedings of WoTUG 98, 1998, which is also incorporated by reference), to produce 

various versions of Handel-C. 

Handel-C is a programming language marketed by Celoxica Limited, 7 - 8 Milton Park, 
15 Abingdon, Oxfordshire, 0X14 4RT, United Kingdom. It enables a software or 
hardware engineer to target directly FPGAs (Field Programmable Gate Array) in a 
similar fashion to classical microprocessor cross-compiler development tools, without 
recourse to a Hardware Description Language, thereby allowing the designer to directly 
realize the raw real-time computing capability of the FPGA. 

20 

Handel-C is designed to enable the compilation of programs into synchronous 
hardware; it is aimed at compiling high level algorithms directly into gate level 
hardware. 

25 The Handel-C syntax is based on that of conventional C so programmers familiar with 
conventional C will recognize almost all the constructs in the Handel-C language. For 
those not skilled in the art, more information about programming with Handel-C is 
provided in the documents entitled "Handel-C User manual," "Handel-C Language 
Reference Manual: version 3," "Handel-C Interfacing to other language code blocks," 
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and "Handel-C Preprocessor Reference Manual," each of which is available from 
Celoxica Limited, 7 - 8 Milton Park, Abingdon, Oxfordshire, 0X14 4RT, United 
Kingdom, and which are herein incorporated by reference in their entirety for all 
purposes. 

5 

Sequential programs can be written in Handel-C just as in conventional C but to gain 
the most benefit in performance from the target hardware its inherent parallehsm must 
be exploited. 

10 Handel-C includes parallel constructs that provide the means for the programmer to 
exploit this benefit in his appUcations. The compiler compiles and optimizes Handel-C 
source code into a file suitable for simulation or a netlist which can be placed and 
routed on a real FPGA. 

15 It should be noted that other programming and hardware description languages can be 
utilized as well, such as VHDL. 

Network-Configurable Hardware 

20 This section will detail the development of a flexible multimedia device according to an 
illustrative embodiment of the present invention using hardware that can be 
reconfigured over a network connection and runs software applications built directly in 
siHcon. 

25 The illustrative platform developed for this purpose is called the Multimedia Terminal 
(MMT). It features no dedicated stored program and no Central Processing Unit (CPU). 
Instead, programs are implemented in Field Programmable Gate Arrays (FPGA) which 
are used both to control peripherals and to process data in order to create CPU-Hke 
flexibility using only reconfigurable logic and a software design methodology. 
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FPGAs can be used to create soft hardware that runs applications without the overhead 
associated with microprocessors and operating systems. Such hardware can be totally 
reconfigured over a network connection to provide enhancements, fixes, or a 
5 completely new application. Reconfigurability avoids obsolescence by allowing the 
flexibility to support evolving standards and applications not imagined when hardware 
is designed. This also allows manufacturers to use Intemet Reconfigurable Logic to 
remotely access and change their hardware designs at any time regardless of where the 
units reside. 

10 

The MMT according to one exemplary embodiment of the present invention achieves 
flexible reconfigurability by using two independent one-million gate Xilinx XCVIOOO 
Virtex FPGAs. One of the FPGAs remains statically configured with networking 
functionality when the device is switched on. The other FPGA is reconfigured with 

15 data provided by the master. The two FPGAs communicate directly via a 36-bit bus 
with 4 bits reserved for handshaking and two 16-bit unidirectional channels as set forth 
in U.S. Patent Application entitled SYSTEM, METHOD, AND ARTICLE OF 
MANUFACTURE FOR DATA TRANSFER ACROSS CLOCK DOMAINS, Attorney 
Docket Number EMB1P015 and filed concurrently herewith and assigned to common 

20 assignee, and which is incorporated herein by reference for all purposes. The protocol 
ensures that reliable communication is available even when the two FPGAs are being 
clocked at different speeds. 

The other components of the MMT are an LCD touch screen, audio chip, 10-Mbps 
25 Ethernet, parallel and serial ports, three RAM banks and a single non-volatile flash 
memory chip. 

FPGA reconfiguration can be performed by using one of two methods. The first 
method implements the Xilinx selectmap programming protocol on the static FPGA 
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which can then program the other. The second method supplies reconfiguration data 
from the network interface or from the flash memory on the MMT. Reconfiguration 
from flash memory is used only to load the GUI for a voice-over-internet protocol 
(VoIP) telephone into the slave FPGA upon power-up, when an application has 
5 finished, or when configuration via the network fails. Network-based reconfiguration 
uses the Hypertext Transfer Protocol (HTTP) over a TCP connection to a, server. A text 
string containing a file request is sent by the MMT to the server which then sends back 
the reconfiguration data (a bitfile), 

10 There has thus been presented a flexible architecture that can run selected applications 
in an FPGA. Now will be described methods ofr writing all those applications and how 
to do it in a reasonable amount of time. Hardware Description Languages (HDL) are 
well-suited to creating interface logic and defining hardware designs with low-level 
timing issues. However, HDL may not be suitable for networking, VoIP, MP3s and 

15 video games. 

To meet the challenges of the system described above, the MMT design can be done 
using Handel-C. It is based on ANSI-C and is quickly learned by anyone that has done 
C software development. Extensions have been put in to support parallelism, variables 
20 of arbitrary width, and other features familiar in hardware design, but it very much 
targets software design methodologies. Unhke some of the prior art C-based solutions 
that translate C into an HDL, the Handel-C compiler directly synthesizes an EDIF 
nethst that can be immediately placed and routed and put onto an FPGA. 

25 The default application that runs on the illustrative embodiment of the MMT upon 
power-up is a Voice over Internet Protocol (VoIP) telephone complete with GUI. The 
voice over internet protocol consists of a call state machine, a mechanism to negotiate 
calls, and a Real Time Protocol (RTP) module for sound processing, A combination of 
messages fi'om the GUI and the call negotiation unit are used to drive the state machine. 
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The protocol implemented by the call negotiation unit is a subset of H.323 Faststart 
(including H225 and Q931). This protocol uses TCP to establish a stream-based 
connection between the two IP telephones. The RTP module is responsible for 
processing incoming sound packets and generating outgoing packets sent over UDP. 

5 

Algorithms for protocols such as RTP^ TCP, IP and UDP can be derived from existing 
public domain C sources. The source code can be optimized to use features available in 
Handel-C such as paralleHsm; this is useful for network protocols which generally 
require fields in a packet header to be read in succession and which can usually be 
10 performed by a pipehne with stages running in parallel. Each stage can be tested and 
simulated within a single Handel-C environment and then put directly into hardware by 
generating an EDIF netlist. Further optimizations and tuning can be performed quickly 
simply by downloading the latest version onto the MMT over the network. 

15 Because of the flexibility of the architecture and to take advantage of Internet 

reconfigurability, a mixed-bag of appHcations can be developed that all run in hardware 
on the MMT. Among them are a fully-functional MPS player with GUI, several video 
games, and some impressive graphics demonstrations that were all developed using 
Handel-C. These applications are hosted as bitfiles on a server that supplies these files 

20 upon demand from the user of the MMT over a network connection. 



25 Interface 

In accordance with the invention, an intuitive interface is provided for defining and 
transferring configuration files from a computer to a device in reconflgurable logic 
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Figure 2 is a flow diagram of a process 200 for providing an interface for transferring 
configuration data to a reconfigurable logic device, such as a Field Programmable Gate 
Array (FPGA), Programmable Logic Device (PLD), or Complex Programmable Logic 
Device (CPLD). In operation 202, images are presented on a display connected to a 
5 reconfigurable logic device. In operation 204, the user is allowed to input a conmiand 
to configure the reconfigurable logic device by selecting one or more of the images. 
The configuration data is transferred from a computer to the reconfigurable logic device 
in operation 206 where it is used to reconfigure the reconfigurable logic device in 
operation 208. 

10 

Other embodiments include a touch sensitive Liquid Crystal Display (LCD), buttons 
presented as bitmapped images to guide a user, interactive configuration of the device 
and its components and provides downloading via the Internet and a wireless network. 

15 In a preferred embodiment, the reconfigurable logic device is capable of saving the 
configuration data for later reuse. In another embodiment, the display is operable for 
inputting commands to control operation of the reconfigurable logic device. 

Example 1 

20 

Figure 3 depicts a display 300 according to one embodiment of the present invention. 
The display is connected to a reconfigurable logic device, such as the one described 
below with respect to Figures 9-15. As an option, the display could be integrated with 
the device. 

25 

An exemplary procedure 400 for initiating the device is shown in Figure 4. The device 
is connected to a network in operation 402 and a power source in operation 404. The 
display is calibrated in operation 406. In operation 408, on connecting power, the 
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device boots with a default programming. In this example, the device boots as an IP 
phone, ready to accept/receive calls. 

Referring again to Figure 3, the display includes several bitmapped buttons with which 
5 a user can input commands for use during a session of Internet telephony. Keypad 
buttons 302 are used to enter IP addresses to place a call. The status window 304 
displays the status of the device. 

In accordance with the present invention, a hardware-based reconfigurable Internet 
10 telephony system can be provided. The system includes a first Field Programmable 
Gate Array (FPGA) that is configured with networking fimctionaiity. A user interface 
is in communication with the first FPGA for presenting information to a user and 
receiving commands from a user. A microphone in communication with the first FPGA 
receives voice data from the user. A communications port is in communication with the 
15 first FPGA and the Internet. The first FPGA is configured to provide a call state 
machine, a call negotiation mechanism, and a Real Time Protocol (RTP) module for 
sound processing. See the discussion relating to Figures 5-7 for more detailed 
information about how to place a call. 

20 According to one embodiment of the present invention, a stream-based connection is 
generated between the system and another Internet telephony system. In another 
embodiment of the present invention, a second FPGA is configured for running a 
second application. In such an embodiment, the first FPGA can preferably configure 
the second FPGA. 

25 

In an embodiment of the present invention, the RTP module processes incoming sound 
packets and generates outgoing sound packets. In a preferred embodiment, the user 
interface includes a touch screen. 
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Figure 5 depicts a process 500 for using the device to place a call. (The process flow is 
from top to bottom.) The number key is pressed and then the IP address to be called is 
entered. As the numbers are typed, they appear in the status window. Once the number 
is entered, the accept button 306 is pressed to make the connection. The word "calling" 
5 appears in the status window to denote that the connection is pending. Upon making 
the connection, "connected" appears in the status window. To end the call, the end 
button 308 is pressed. 

Figure 6 illustrates the process 600 to answering a call. The status window displays 
10 "incoming call" and the device may sound a tone. The user selects the accept button to 
answer the call. Selection of the end button terminates the call. 

Figure 7 depicts a configuration screen 700 for setting various parameters of the 
telephony functions. The buttons 702, 704 having the plus and minus signs are used to 
15 increase and decrease speaker volume, microphone volume, etc. Mute buttons 706 and 
display brightness buttons 708. 

One skilled in the art will recognize that the device operates much like a traditional 
telephone and therefore, can include many of the features found in such telephones. 

20 

The screen shown in Figure 3 includes several buttons other than those discussed above. 
Selecting the mp3 button 310 initiates a download sequence ordering the device to 
request configuration information to reconfigure the device to play audio in the mp3 
format. Once the configuration information is received, the device reconfigures itself to 
25 play mp3 audio. 

Upon reconfiguration, the display presents the screen 800 shown in Figure 8A. The 
various buttons displayed include a play button 802, a stop button 804, track back and 
track forward buttons 806, 808, a pause button 810, a mute button 812, volume up and 

EMB1P022 



-26- 



down buttons 814, 816 and an exit button 818 that returns to the default program, in this 
case, the IP telephony program. 

Upon selection of the saver button 820, the configuration information is stored for 
5 reconfiguration of the device without requiring a download, if the device has access to 
sufficient storage for the information. 

Referring again to Figure 3, selection of the game button 312 initiates a download 
sequence ordering the device to request configuration information to reconfigure the 
10 device to allow playing of a game. 

Multimedia Device 

Figure 8B depicts a process 850 for providing a hardware-based reconfigurable 
15 multimedia device, hi operation 852, a default multimedia application is initiated on a 
reconfigurable multimedia logic device, which can be a device similar to that discussed 
with respect to Figures 9-15. A request for a second multimedia appUcation is received 
fi*om a user in operation 854. Configuration data is retrieved fi"om a data source in 
operation 856, and, in operation 858, is used to configure the logic device to run the 
20 second multimedia application, hi operation 860, the second multimedia apphcation is 
run on the logic device. 

According to the present invention, the multimedia applications can include an audio 
application, a video application, a voice-based application, a video game application, 
25 and/or any other type of multimedia apphcation. 

Li one embodiment of the present invention, the configuration data is retrieved fi-om a 
server located remotely fi:'om the logic device utihzing a network such as the hitemet. 
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In another embodiment of the present invention, the logic device includes one or more 
Field Programmable Gate Arrays (FPGAs), Ideally, a first FPGA receives the 
configuration data and uses the configuration data to configure a second FPGA. 
Another embodiment of the present invention includes first and second FPGAs that are 
5 clocked at different speeds, hi a preferred embodiment, the default multimedia 

apphcation and the second multimedia application are both able to run simultaneously 
on the logic device, regardless of the number of FPGAs. 

Illustrative Reconfigurable Logic Device 

10 

A reconfigurable logic device according to a preferred embodiment of the present 
invention includes a bi-directional 16 bit communications driver for allowing two 
FPGAs to talk to each other. Every message ft-om one FPGA to the other is preceded by 
a 16 bit ID, the high eight bits of which identify the type of message (AUDIO, FLASH, 
15 RECONFIGURATION etc. , .) and the low identify the particular request for that 
hardware (FL ASHORE AD etc. . .). The id codes are processed in the header file 
i^Oserver.h, and then an appropriate macro procedure is called for each type of message 
(e.g. for AUDIO AudioRequest is called) which then receives and processes the main 
body of the communication. 

20 

Preferably, the FPGAs are allowed to access external memory. Also preferably, 
arbitration is provided for preventing conflicts between the FPGAs when the FPGAs 
access the same resource. Further, the need to stop and reinitiaUze drivers and hardware 
when passing from one FPGA to the other is removed. 

25 

As an option, shared resources can be locked fi*om other processes while 
communications are in progress. This can include communications between the FPGAs 
and/or communication between an FPGA and the resource. 
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In one embodiment of the present invention, an application on one of the FPGAs is 
allowed to send a command to another of the FPGAs. In another embodiment of the 
present invention, one or more of the FPGAs is reconfigured so that it can access the 
resource. 

5 

In use, the server process requires a number of parameters to be passed to it. These are: 



• PID: Used for locking shared resources (such as the FLASH) fi^om other 
processes while communications are in progress. 

10 

• usendCommand, uSendLock: A channel allowing appUcations on FPO to send 
commands to applications on FPl and a one-bit locking variable to ensure the 
data is not interleaved with server-sent data. 



15 • uSoundOut, uSoundIn: Two channels mirroring the function of the audio 
driver. Data sent to uSoundOut will be played (assuming the correct code in 
FPl) out of the MMT2000 speakers, and data read from uSoundIn is the input to 
the MMT2000 microphone. The channels are implemented in such a way that 
when the sound driver blocks, the communication channel between FPGAs is 

20 not held up. 



• MF3Ruii: A one bit variable controlling the MPS GUI. The server will activate 
or deactivate the MPS GUI on receipt of commands from FPl . 



25 • ConfigAddr: A 23 bit channel controlling the reconfiguration process. When 
the flash address of a vaUd FPGA bitfile is sent to this channel, the server 
reconfigures FPl with the bitmap specified. 
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The data transfer rate between the two FPGAs in either direction is preferably about 16 
bits per 5 clock cycles (in the clock domain of the slowest FPGA), for communicating 
between FPGAs that may be running at different clock rates. 

5 Several Handel-C macros which may be generated for use in various implementations 
of the present invention are set forth in Table 1, The document "Handel-C Language 
Reference Manual: version 3," incorporated by reference above, provides more 
information about generating macros in Handel-C. 

10 Table 1 



Filename 


Type 


Macro Name 


Purpose 


FpOserver.h 


Resource server 


FpOserverQ 


Resource server for FPO for the 
MMT2000 IPPhone/MP3 
project 


Audiorequest.h 


Audio Server 


AudioRequestO 


Audio server for allowing 
sharing of sound hardware 


Flashrequest.h 


Data server 


FlashRequestQ 


Server for allowing FPl access 
to the FLASH memory 


Mp3request.h 


MP3 server 


MP3RequestO 


Server to control the MP3 
appHcation and feed it MP3 
bitstream data when requested. 


Reconfigurerequest.h 


Reconfiguration 


Reconfigurereq 


Allows FPl to request to be 




hardware 


uestO 


reconfigured, at an application 
exit. 


Fpgacomms.h 


Communications 
hardware 


FpgacommsQ 


Implements two unidirectional 
16 bit channels for 
communicating between the 
two FPGAs 
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Illustrative Device Development Platform 

Figure 9 is a diagrammatic overview of a board 900 of the resource management device 
5 according to an illustrative embodiment of the present invention. It should be noted that 
the following description is set forth as an illustrative embodiment of the present 
invention and, therefore, the various embodiments of the present invention should not 
be limited by this description. As shown, the board can include two Xilinx Virtex™ 
2000e FPGAs 902, 904, an hitel StrongARM SAl 1 10 processor 906, a large amount of 
10 memory 908, 910 and a number of I/O ports 912. Its main features are Usted below: 

Two XCV 2000e FPGAs each with sole access to the following devices: 
Two banks (1 MB each) of SRAM (256Kx32 bits wide) 
Parallel port 
15 Serial port 

ATA port 

The FPGAs share the following devices: 
VGA monitor port 
20 Eight LEDs 

2 banks of shared SRAM (also shared with the CPU) 
USB interface (also shared with the CPU) 

The FPGAs are cormected to each other through a General Purpose I/O (GPIO) bus, a 
25 32 bit SelectLink bus and a 32 bit Expansion bus with connectors that allow external 
devices to be connected to the FPGAs. The FPGAs are mapped to the memory of the 
StrongARM processor, as variable latency I/O devices. 

The Intel StrongARM SAl 1 10 processor has access to the following: 
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64Mbytes of SDRAM 
16Mbytes of FLASH memory 
LCD port 
IRDA port 
5 Serial port 

It shares the USB port and the shared SRAM with the FPGAs. 

In addition to these the board also has a Xilinx XC95288XL CPLD to implement a 
number of glue logic functions and to act as a shared RAM arbiter, variable rate clock 
10 generators and JTAG and MultiLinx SelectMAP support for FPGA configuration. 

A number of communications mechanisms are possible between the ARM processor 
and the FPGAs. The FPGAs are mapped into the ARM's memory allowing them to be 
accessed fi-om the ARM as through they were RAM devices. The FPGAs also share two 
15 1 MB banks of SRAM with the processor, allowing DMA transfers to be performed. 
There are also a number of direct connections between the FPGAs and the ARM 
through the ARM's general purpose I/O (GPIO) registers. 

The board is fitted with 4 clocks, 2 fixed fi-equency and 2 PLLs. The PLLs are 
20 programmable by the ARM processor. 

The ARM is configured to boot into Angel, the ARM onboard debugging monitor, on 
power up and this can be connected to the ARM debugger on the host PC via a serial 
link. This allows appUcations to be easily developed on the host and run on the board. 

25 

There are a variety of ways by which the FPGAs can be configured. These are: 

• By an external host using JTAG or MultiLinx SelectMAP 

• By the ARM processor, using data stored in either of the Flash RAMs or data 
acquired through one to the serial ports (USB, ERDA or RS232). 
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• By the CPLD from power-up with data stored at specific locations in the FPGA 
FlashRAM. 

• By one of the other FPGAs. 

5 Appendices A and B set forth the pin definition files for the master and slave FPGAs on 
the board. Appendix C describes a parallel port interface that gives full access to all the 
parallel port pins. Appendix D discusses a macro library for the board of the present 
invention. 

10 StronaARM 

The board is fitted with an Intel SAl 1 10 Strong ARM processor. This has 64Mbytes of 
SDRAM connected to it locally and 16Mbytes of Intel StrataFLASH™ from which the 
processor may boot. The processor has direct connections to the FPGAs, which are 
15 mapped to its memory map as SRAM hke variable latency I/O devices, and access to 
various I/O devices including USB, IRDA, and LCD screen connector and serial port. It 
also has access to 2MB of SRAM shared between the processor and the FPGAs. 

Memory Map 

20 

The various devices have been mapped to the StrongARM memory locations as shown 
in Table 2: 



Table 2 


Address Location 


Contents 


0x00000000 


Flash Memory 16 MB 16 bits wide. 


0x08000000 


CPLD see CPLD section for list of registers 


0x10000000 


Shared RAM bank 1 256K words x32 


0x18000000 


Shared RAM bank 0 256K words x32 
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0x40000000 


FPGA access ( nCS4) 


0x48000000 


FPGA access (nCS5) 


OxCOOOOOOO 


SDRAM bank 0 


OxDOOOOOOO 


SDRAM bank 1 



The suggested settings for the StrongARM's internal memory configuration registers 
are shown in Table 3: 

5 

Table 3 



Register 


Value 


MDCNFG 


0xA165 A165 


MDREF 


Ox 8230 02E1 


MDCADSO 


Ox 5555 5557 


MDCASl 


Ox 5555 5555 


MDCAS2 


Ox 5555 5555 


MSCO 


0x2210 4B5C 


MSCl 


Ox 0009 0009 


MSC2 


Ox 2210 2210 



Where the acronyms are defined as; 
10 MDCNFG - DRAM configuration register 

MSC0,1 j2 - Static memory control registers for banks 0,1,2 

MDREF "DRAM refi-esh control register 

MDCAS - CAS rotate control register for DRAM banks 
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The CPU clock should be set to 19L7MHz (CCF = 9). Please refer to the StrongARM 
Developers Manual, available from Intel Corporation, for further information on how to 
access these registers. 

5 FLASH memory 

The Flash RAM is very slow compared to the SRAM or SDRAM, It should only be 
used for booting from; it is recommended that code be copied from Flash RAM to 
SDRAM for execution. If the StrongARM is used to update the Flash RAM contents 
10 then the code must not be running from the Flash or the programming instructions in the 
Flash will get corrupted, 

SDRAM 

15 A standard 64MB SDRAM SODIMM is fitted to the board and this provides the bulk of 
the memory for the StrongARM. Depending upon the module fitted the SDRAM may 
not appear contiguous in memory. 

Shared RAM banks 

20 

These RAM banks are shared with both FPGAs. This resource is arbitrated by the 
CPLD and may only be accessed once the CPLD has granted the ARM permission to do 
so. Requesting and receiving permission to access the RAMs is carried out through 
CPLD register 0x10. Refer to the CPLD section of this document for more information 
25 about accessing the CPLD and its internal registers from the ARM processor. See 
Appendix D. 

FPGA access 

30 The FPGAs are mapped to the ARM's memory and the StrongARM can access the 
FPGAs directly using the specified locations. These locations support variable length 
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accesses so the FPGA is able to prevent the ARM from completing the access until the 
FPGA is ready to receive or transmit the data. To the StrongARM these will appear as 
static memory devices, with the FPGAs having access to the Data, Address and Chip 
Control signals of the RAMs. 

The FPGAs are also connected to the GPIO block of the processor via the SAIO bus. 
The GPIO pins map to the SAIO bus is shown in Table 4. 



Table 4 



GPIO pins 


SAIO lines 


0,1 


0,1 


10, 11 


2,3 


17-27 


4-14 



Of fliese SAIO[0:10] connect to the FPGAs and SAIO[0:14] connect to connector CN25 
on the board. The FPGAs and ARM are also able to access 2MB of shared memory, 
allowing DMA transfers between the devices to be performed. 

J/0 Devices 

The following connectors are provided: 

• LCD Interface connector with backlight connector 

• IRDA connector (not 5 V tolerant) 

• GPIO pins (not 5 V tolerant) 

• Serial port 

• Reset button to reboot the StrongARM 
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The connections between these and the ARM processor are defined below in Tables 5- 
8: 



Table 5: ARM - LCD connections (CN27) 



LCD connector 
pin no. 


ARM pin 


Description 




10..6 


LCD0..4 


BLUE0..4 


18..16 


LCD5..7 


GREEN0..2 


15..13 


GPI02..GPI04 


GREEN3..5 


24..20 


GPI05..GPI09 


RED0..RED4 




27 


LCD_FCLK 


16 


28 


LCD_LCLK 


17 


29 


LCD_PCLK 


18 


4 


LCD_BIAS 


19 


2,3, (1) 




+5V 


(1), 5,11,12,19, 
25,26,30 




GND 


Table 6: ARM IRDA connections (CN8A) 


IRDA 
connector pin 


ARM pin 


Description 




no. 








2 


RxD2 




1 


TxD2 




3 


GPI012 




4 


GPI013 




5 


GPI014 





EMB1P022 



-37- 



6,8 




GND 


7 




+3.3V 



Table 7: ARM GPIO - CN20AP connections 



CN20AP pin no. 


GPIO pins 


2,3 


0,1 


4,5 


10, 11 


6-16 


17-27 


17,19 


+3.3V 


18,20 


GND 



5 

Table 8: ARM - Serial Port connections (CN23) 



Serial Port 
connector pin no. 


ARM pin 


Description 


2 


RxDl 




8 


RxD3 




3 


TxDl 




7 


TxD3 




1,4,6,9 




Not connected 


5 




GND 



The serial port is wired in such away that two ports are available with a special lead if 
10 handshaking isn't required. 

Angel 
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Angel is the onboard debug monitor for the ARM processor. It commimicates with the 
host PC over the serial port (a null modem serial cable will be required). The ARM is 
setup to automatically boot into Angel on startup - the startup code in the ARM's Flash 
RAM will need to be changed if this is not required. 

5 

When Angel is in use 32MBs of SDRAM are mapped to 0x00000000 in memory and 
are marked as cacheable and bufferable (except the top 1MB). The Flash memory is 
remapped to 0x40000000 and is read only and cacheable. The rest of memory is 
mapped one to one and is not cacheable or bufferable. 

10 

Under Angel it is possible to run the FPGA programmer software which takes a bitfile 
from the host machine and programs the FPGAs with it. As the .bit files are over 1MB 
in size and a serial link is used for the data transfer this is however a very slow way of 
configuring the FPGAs. 

15 

Virtex FPGA^s 



Two Virtex 2000e FPGAs are fitted to the board. They maybe programmed from a 
variety of sources, including at power up from the FLASH memory. Although both 
20 devices feature the same components they have different pin definitions; Handel-C 
header files for the two FPGAs are provided. 

One of the devices has been assigned 'Master', the other 'Slave'. This is basically a 
means of identifying the FPGAs, with the Master having priority over the Slave when 
25 requests for the shared memory are processed by the CPLD. The FPGA below the serial 
number is the Master. 



One pin on each of the FPGAs is defined as the Master/Slave define pin. This pin is 
pulled to GND on the Master FPGA and held high on the Slave. The pins are: 
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MasterFPGA:C9 
Slave FPGA: D33 

5 The following part and fanaily parameters should be used when compiling a Handel-C 
program for these chips: 

set family = Xilinx4000E; 
set part = "XV2000e-6-f g680'' ; 

10 

Clocks 

Two socketed clock oscillator modules may be fitted to the board. CLKA is fitted with a 
50 MHz oscillator on dispatch and the CLKB socket is left to be fitted by the user 
15 should other or multiple fi*equencies to required. A +5V oscillator module should be 
used for CLKB. 

Two on board PLLs, VCLK and MCLK, provide clock sources between 8MHz and 
lOOMHz (125MHz may well be possible). These are programmable by the ARM 
20 processor. VCLK may also be single stepped by the ARM. 

This multitude of clock sources allows the FPGAs to be clocked at different rates, or to 
let one FPGA have multiple clock domains. 

25 The clocks are connected to the FPGAs, as described in Table 9 and Appendices A and 
B: 

Table 9 



Clock Master FPGA Slave FPGA 



EMB1P022 



-40- 





pm 


pm 


CLKA 


A20 


D21 


CLKB 


D21 


A20 


VCLK 


AW19 


AU22 


MCLK 


AU22 


AW19 



Programming the FPGAs 

5 The FPGAs may be programmed from a variety of sources: 

• Parallel III cable JTAG 

• MultiLinx JTAG 

• MultiLinx SelectMAP 

• ARM processor 

1 0 • From the other FPGA 

• Power up from FLASH memory ( FPGA FLASH memory section). 

When using any of the JTAG methods of programming the FPGAs you must ensure that 
the Bitgen command is passed the option "-g startupclk:jtagclk You will also need a 

15 .jed file for the CPLD or a .bsd file, which may be found in 

"Xilinx\xc9500xMata\xc95288XLjql44.bsd". The StrongARM also requires a ,bsd 
file, which may be found on the hitel website http :// developer . intel .com/desi gn/ 
stronR/bsdl/sal 1 1 0 bl .bsd . When downloaded this file will contain HTML headers and 
footers which will need to be removed first. Alternatively, copies of the required .bsd 

20 files are included on the supplied disks. 

The JTAG chain 1000 for the board is shown in Figure 10. 
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The connections when using the Xilinx Parallel III cable and the 'JTAG Programmer' 
are set forth in Table 10: 



Table 10: Parallellll Cable JTAG 



CN24 pin number 


JTAG Connector 


1 


TMS 


2 


cut pin 


3 


TDI 


4 


TDO 


5 


not used 


6 


TCK 


7 


not used 


8 


GND 


9 


POWER 



With the Xilinx cables it may be easier to fit the flying ends into the Xilinx pod so that a 
number of cables may be connected to the board in one go. 



10 MultiLinx JTAG 



15 



The board has support for programming using MultiLinx. CN3 is the only connector 
required for JTAG programming with MultiLinx and is wired up as described in Table 
IL (Note that not used signals may be connected up to the MultiLinx if required.) 

Table 11 



CN3 pin number 


MultiLinx 


1 


not used 


3 


RD(TDO) 


5 


not used 


7 


not used 


9 


TDI 



CN3 pin number 


MultiLinx 


2 


Vcc 


4 


GND 


6 


not used 


8 


not used 


10 


not used 
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11 


TCK 


13 


IMS 


15 


not used 


17 


not used 


19 


not used 



12 


not used 


14 


not used 


16 


not used 


18 


not used 


20 


not used 



MultiLinx SelectMAP 

5 JP3 must be fitted when using MulitLinx SelectMap to configure the FPGAs. This link 
prevents the CPLD from accessing the FPGA databus to prevent bus contention. This 
also prevents the ARM accessing the FPGA Flash memory and from attempting FPGA 
programming from power up. Connectors CN3 and CN4 should be used for Master 
FPGA programming and CNIO and CNl 1 for programming the Slave FPGA. See 

10 Tables 12-13. 



Table 12 



CN3/CN10 pin 


MultiLinx 


number 




1 


not used 


3 


not used 


5 


not used 


7 


not used 


9 


not used 


11 


not used 


13 


not used 


15 


not used 


17 


not used 


19 


not used 



CN3/CN10pin 


MultiLinx 


number 




2 


+3v3 


4 


GND 


6 


not used 


8 


CCLK 


10 


DONE 


12 


not used 


14 


nPROG 


16 


nlNIT 


18 


not used 


20 


not used 
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Table 13 



CN4/CN11 pin 


MultiLinx 


number 




1 


cso 


3 


not used 


5 


not used 


7 


not used 


9 


not used 


11 


not used 


13 


RS 




(RDWR) 


15 


not used 


17 


DY/BUSY 


19 


not used 



CN4/CN11 pin 


MultiLinx 


number 




2 


DO 


4 


Dl 


6 


D2 


8 


D3 


10 


D4 


12 


D5 


14 


D6 


16 


D7 


18 


not used 


20 


not used 



10 



15 



In practice MultiLinx SelectMap was found to be a very tiresome method of 
programming the FPGAs due to the large number of flying leads involved and the fact 
that the lack of support for multi FPGA systems means that the leads have to connected 
to a different connector for configuring each of the FPGA. 

ARM processor 

The ARM is able to program each FPGA via the CPLD. The FPGAs are set up to be 
configured in SelectMap mode. Please refer to the CPLD section of this document and 
Xilinx Datasheets on Virtex configuration for more details of how to access the 
programming pins of the FPGAs and the actual configuration process respectively. An 
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ARM program for configuring the FPGAs with a .bit file firom the host PC under Angel 
is suppUed. This is a very slow process however as the file is transferred over a serial 
link. Data could also be acquired fi*om a variety of other sources including USB and 
IRD A or the onboard Flash RAMs and this should allow an FPGA to be configured in 
5 under 0.5 seconds. 



Configuring one FPGA from the other FPGA 



One FPGA is able to configure the other through the CPLD in a manner similar to when 
10 the ARM is configuring the FPGAs. Again, please refer to the CPLD section of this 
document and the Xihnx data sheets for more information. 



Configuring on power up firom Flash Memory 



15 The board can be set to boot the FPGAs using configuration data stored in this memory 
on power up. The following jumpers should be set if the board is required to boot fi*om 
the Flash RAM: 

• JPl should be fitted if the Master FPGA is to be programmed from power up 

• JP2 should be fitted if the Slave FPGA is to be programmed from power up. 

20 

If these jumpers are used the Flash RAM needs to be organized as shown in Table 14: 



Table 14 



Open 


Open 


All of FLASH memory available for FLASH 






data 


Fitted 


Open 


Master FPGA configuration data to start at 






address 0x0000 


Open 


Fitted 


Slave FPGA configuration data to start at 
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address 0x0000 


Fitted 


Fitted 


Master FPGA configuration data to start at 
address 0x0000 followed by slave FPGA 
configuration data. 



The configuration data must be the configuration bit stream only, not the entire .bit file. 
The ,bit file contains header information which must first be stripped out and the bytes 
of the configuration stream as stored in the .bit file need to be mirrored - i.e. a 
5 configuration byte stored as 001 1 0001 in the bit file needs to be apphed to the FPGA 
configuration data pins are 100011 00. 

For more information on configuration of Xilinx FPGAs and the .bit format refer to the 
appropriate Xilinx datasheets. 

10 

FPGA FLASH Memory 

16 MB of Intel StrataFLASH ™ Flash memory is available to the FPGAs. This is 
shared between the two FPGAs and the CLPD and is connected directly to them. The 
15 Flash RAM is much slower than the SRAMs on the board, having a read cycle time of 
120ns and a write cycle of around 80ns. 

The FPGAs are able to read and write to the memory directly, while the ARM processor 
has access to it via the CPLD. Macros for reading and writing simple commands to the 
20 Flash RAM's internal state machine are provided in the klib.h macro library (such as 
retrieving identification and status information for the RAM), but it is left up to the 
developer to enhance these to implement the more complex procedures such as block 
programming and locking- The macros provided are intended to illustrate the basic 
mechanism for accessing the Flash RAM. 

25 
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When an FPGA requires access to the Flash RAM it is required to notify the CLPD by 
setting the Flash Bus Master signal low. This causes the CPLD to tri-state its Flash 
RAM pins to avoid bus contention. Similarly, as both FPGAs have access to the Flash 
RAM over a shared bus, care has to be taken that they do not try and access the memory 
5 at the same time (one or both of the two FPGAs may be damaged if they are driven 
against each other). It is left up to the developer to implement as suitable arbitration 
system if the sharing of this RAM across both FPGAs is required. 

The connections between this RAM and the FPGAs are set forth in Table 15: 

10 

a Table 15 



I 1 


Flash RAM pin 


Master FPGA 


Slave FPGA pin 




FDO 


r? 


r? 




FDI 


P4 


P4 




Fn? 


P^ 


P^ 




FF)^ 


R1 


R1 




Fn4 


AD^ 


AD^ 




Fns 


AG? 


AG? 




FD6 


AHl 


AHl 




FD? 


AR4 


AR4 




Fnx 


R?1 


A?1 




FDQ 


r?^ 


r?^ 




Fmn 


A?1 


R?1 




FD11 


K?? 


D?^ 




FDI 7 


R?n 


A?? 




FDn 


D?? 


F?-^ 




FDI 4 


r,?i 


R9? 




FDI'^ 


RIQ 


R?4 




FAO 


A?J? 


A14 




FA1 


r?8 


Difi 




FA? 


R?7 


R1S 




FA^ 


D?7 


rifi 




FA4 


A?7 


A1S 




FAS 


r?7 


F17 




FAfi 


R?fi 


Rlfi 




FA7 


D?6 


D17 




FAS 


r?fi 


r,i7 




FAQ 


A?fi 


Alfi 




FAin 


D?5 


FIX 
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FAl 1 


R25 


R17 


FA17 


r7S 




FAH 


A7S 


A17 


FA14 


D74 


ri8 


FAIS 


A74 


R1R 


FA16 


R7^ 


niQ 


FA17 


r74 


AIR 


FA18 


A7^ 


r.iQ 


FAIQ 


R74 


R1Q 


FA70 


R77 


( .71 


n M / f 


p./ T 


ri77 


FA77 


A 77 


R9n 


FA7^ 


n7'^ 


F.?? 


nrR 






nWF 


AIR 


r?4 




niQ 




nOF 




r.?4 


tlBYTE 


C18 


B24 


F bus master oin 


C17 


C26 



5 Each FPGA has two banks of local SRAM, arranged as 256K words x 32bits. They 
have an access time of 15ns. 

In order to allow single cycle accesses to these RAMs it is recommended that the 
external clock rate is divided by 2 or 3 for the Handel-C clock rate. I.e. include the 
10 following line in your code: 

set clock = external_divide "A20" 2; // or higher 

For an extemal__divide 2 clock rate the RAM should be defined as: 

15 

macro expr sram_local_bankO_spec = 

{ 
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offchip = 1, 

wegate = 1 , 

data = DATA_pins, 

addr = ADDRESS_j)ins , 

cs = { "E2", "Fl", "J4", "F2", 

"H3 " } , 

we = { "H4" }, 
oe = { "El" } 

}; 

If the clock is divided by more than 2 replace the wegate parameter with 

westart=2, 
welength=l, 

The connections to these RAMs are as follows: 



Table 16 



SRAM Pin 


Master 


Slave FPGA 


Master 


Slave FPGA 




FPGA 


SRAMO 


FPGA 


SRAMl 




SRAMO 




SRAMl 




D31 


Wl 


AA39 


AT3 


AR37 


D30 


AB4 


AB35 


AP3 


AR39 


D29 


AB3 


Y38 


AR3 


AR36 


D28 


W2 


AB36 


AT2 


AT38 


D27 


AB2 


Y39 


AP4 


AR38 


D26 


VI 


AB37 


AR2 


AP36 


D25 


AA4 


AA36 


ATI 


AT39 


D24 


V2 


W39 


AN4 


AP37 


D23 


AA3 


AA37 


ARl 


AP38 


D22 


Ul 


W38 


AN3 


AP39 
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D21 


W3 


W37 


AP2 




D20 


U2 


V39 


AN2 


AiN JO 


D19 


W4 


W36 


API 


/ 


D18 


Tl 


U39 


AM4 




D17 


V3 


V38 


A XT 1 

ANl 


AiVi J O 


D16 


T2 


U38 


AM3 


AIVIjo 


D15 


V4 


V37 


ATA 

AlA 


AM J / 


D14 


V5 


T39 


AM2 


AT 1^ 


D13 


U3 


V36 


AL3 


AMiV 


D12 


R2 


T38 


AMI 


A T in 
ALi / 


Dll 


U4 


V35 


AL2 


AT 


DIO 


PI 


R39 


ALT 


A li^l^ 

AJs.io 


D9 


U5 


U37 


AK4 


AT 


D8 


P2 


U36 


AK2 


Al^'i7 


D7 


T3 


R38 


AK3 


AKJo 


D6 


Nl 


U35 


AKl 


A T'iA 
AJ JO 


D5 


N2 


P39 


AJ4 


A l^'iO 
AivjV 


D4 


T4 


T37 


AJ1 


A Ml 
AJ J / 


D3 


Ml 


P38 


A.T3 


A T'iC 


D2 


R3 


T36 


AH2 


Arl J / 


Dl 


M2 


N39 


AJ2 


A T'iQ 


DO 


R4 


N38 


AH3 


ATJIS 
AHJo 












A17 


LI 


R37 


AG! 




A16 


L2 


M39 


AG4 




A15 


N3 


R36 


AF2 




A14 


Kl 


M38 


AG3 




A13 


N4 


P37 


AFl 


ACtJ / 


A12 


K2 


L39 


AF4 


Ar 


All 


M3 


P36 


AF3 


A IT'S 

Ario 


AlO 


Jl 


N37 


AE2 




A9 


L3 


L38 


AE4 


Ar 3 / 


A8 


J2 


N36 


AE 


Ar Jo 


A7 


L4 


K39 


AE3 


Ac/jV 


A6 


rl 1 


M37 


AD2 


AE36 


A5 


K3 


K38 


AD4 


AD38 


A4 


H2 


L37 


ADl 


AE37 


A3 


K4 


.T39 


AC1 


AD39 


A2 


Gl 


L36 


ABl 


AD36 


Al 


Ci2 


13 8 


ACS 


AC38 


AO 


J3 


K37 


AA2 


AC39 
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CS 


E2, Fl, J4, 


J Jo, rlio. 








F2, H3 


J37, K36, 


AA1,AC3, 


AB39, AC35, 






H39 


Yl 


AC37 


WE 


H4 


G38 


Y2 


A A3 8 


OE 


El 


G39 


AC2 


AC36 


D31 


Wl 


AA39 


AT3 


AR37 



Shared SRAM 

5 Each FPGA has access two banks of shared SRAM, again arranged as 256K words x 
32bits. These have a 16ns access time. A series of quick switches are used to switch 
these RAMs between the FPGAs and these are controlled by the CPLD which acts as an 
arbiter. To request access to a particular SRAM bank the REQUEST pin should be 
pulled low. The code should then wait until the GRANT signal is pulled low by the 

1 0 CPLD in response. 

The Handel-C code to implement this is given below: 

// define the Request and Grant interfaces for 
15 the Shared SRAM 

unsigned 1 shared_bankO_request=l ; 
unsigned 1 shared_bankl_request=l ; 

interface bus_out() 
20 sharedbkOreg (shared__bankO_request ) with 

sram_shared__bankO_request_pin; 
interface bus_out() 

sharedbklreg { shared__bankl_request ) with 
sram shared_bankl__request_pin; 
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interface bus_clock_in (unsigned 1) 
shared_bankO_grant ( ) with 
sram_shared_bankO_grant__pin ; 
interface bus_clock_in (unsigned 1) 
5 shared_bankl_grant 0 with 

sram_shared_bankl_grant_pin ; 

// Access to a shared RAM bank 
{ 

10 shared_bankO__request = 0 ; 

while (shared_bankO_grant . in) delay; 

} 

// perform accesses .... 
15 // release bank 

shared_bankO_request=l ; 

The RAMs should be defined in the same manner as the local RAMs. (See above.) 

20 The connections to the shared RAMs are given in Table 17: 



Table 17 



Shared Master FPGA 
SRAM pin Shared SRAM 
0 


Slave FPGA 
Shared SRAM 
0 


Master FPGA 
Shared SRAM 1 


Slave FPGA 
Shared 
SRAMl 


D31 


AA39 


Wl 


AR37 


AT3 


D30 


ABBS 


AB4 


AR39 


AP3 


D29 


Y38 


AB3 


AR36 


AR3 


D28 


AB36 


W2 


AT38 


AT2 


D27 


Y39 


AB2 


AR38 


AP4 
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A A A 


A Ad 


/\ 1 jy 


AT1 
Al 1 


no /I 


w jy 


V jL 


/\r J / 


A XT A 


L>Z3 


A A 


A A ^ 
AAj 


AD'J Q 
AJl JO 


AD 1 


L>z2 


W Jo 


TT1 
U 1 


AD^Q 
Ar jy 


AiN J 


T^O 1 

uZi 


W J / 


W J 


AiN JO 


ADO 
ArZ 


UzU 


\ jy 


TTO 

Uz 


AiN JO 


AXTO 
AINZ 


T^l Ci 


Wio 


WTA 

W4 


A ATI 7 
AJNj / 


A Dl 

Ar 1 


■p\i o 
JJlo 




1 1 


AiN jy 


A \AA 


Ul7 


V JO 


V J 


AM JO 


AXT1 

AiNl 


Ulo 


U JO 


TO 
1 Z 


AiVl J O 


AiVl J 




V J / 


V4 


AiVl J / 


A T /I 
AL4 


■p\ 1 A 

D14 


1 jy 


V J 


A T 1^ 

ALjo 


A A /TO 

AM2 


Uli 


Vio 


Uj 


A A/T'JO 

AMjy 


ATI 

ALj 


D12 


1 JO 


DO 

Kz 


A T in 

AJL J / 


A Ayf 1 
AMI 


Ull 


Vjj 


T J A 
U4 


A T IC 

ALjo 


A T O 

AL2 


DIU 


Kjy 


Dl 

r 1 


AJvjo 


ATI 

ALl 


uy 


UJ / 


Uj 


A T IQ 

ALjy 


\V A 


Do 


U JO 


DO 

rZ 


AJVJ / 


A v^i 
AJvZ 


L/ / 


Kjo 


1 J 


AJvJo 


AJvJ 


JJo 


U J J 


IN 1 


A T^^ 
AJ JO 


A'\^^ 

AJs.1 


JJj 


rjy 


"MO 
iNZ 


ATT^Q 
Aivjy 


A ^A 

AJH- 


U4 


1 J / 


14 


A 

AJ J / 


A Tl 
A J 1 




r JO 


A/fl 
iVll 


AJ JO 


A T^ 
AJ J 


D2 


1 JO 


D 'I 


A uin 
AH J / 


A TJO 

Arl2 


1 

Dl 


Njy 


MZ 


AJjy 


A TO 

AJ2 


T^A 

DO 


JNjo 


D /I 

K4 


An JO 


A TJ'2 

Arij 












AIT 

A17 


Kj7 


T 1 

Li 


A l-T'JO 


Aval 


A 1 


Mjy 


T O 


A rnQ 
AvjJO 


A rxA 


A 1 C 

A15 


Kjo 


JN J 


ALtjo 


A T?0 

Ar2 


A14 


iViJo 




A mo 


A m 


A 1 0 

A13 


r J / 


XT/1 

jN4 


A 


A Tri 
Ar 1 


AIT 

A12 


T 'JO 

Ljy 


T^O 


Ar jy 


Ar4 


All 

Ai 1 


r JO 


ivlj 


Ar JO 


Ar J 


A 1 rt 
AlU 


IN J / 


Tl 
J 1 


AJijo 


AThO 
AriZ 


A9 


L38 


L3 


AF37 


AE4 


A8 


N36 


J2 


AF38 


AEl 


A7 


K39 


L4 


AE39 


AE3 


A6 


M37 


HI 


AE36 


AD2 


A5 


K38 


K3 


AD38 


AD4 


A4 


L37 


H2 


AE37 


ADl 
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A2 


L36 


Gl 


AD36 


ABl 


Al 


J38 


G2 


AC38 


ACS 


AO 


K37 


J3 


AC39 


AA2 


CS 


J36, H39, K36, 


E2,H3,F2,J4,F1 


AC37, AD37, 


AB5, AC3, 




H38, J37 




AB38, AC35. 


Y1,AA1, 








AB39 


AC4 


WF. 


G38 


m 




Y? 


OE 


G39 


El 


AC36 


AC2 


REQUEST 


A17 


A25 


D18 


C25 


GRANT 


B17 


B25 


E18 


D25 



Connections to the StrongARM processor 

5 The FPGAs are mapped to the StrongARMs memory as variable latency I/O devices^ 
and are treated as by the ARM as though they were 1024 entry by 32bit RAM devices. 
The address, data and control signals associated with these RAMs are attached directly 
to the FPGAs. The manner in which the FPGAs interact with the ARM using these 
signals is left to the developer. 

10 

The connections are as shown in Table 18: 



Table 18 



ARM pin 


Master FPGA pin 


Slave FPGA pin 


ARMA9 


A33 


cn 


ARMA8 


C31 


Bll 


ARMA7 


B32 


C12 


ARMA6 


B31 


All 


ARMAS 


A32 


D13 


ARMA4 


D30 


B12 


ARMA3 


A31 


C13 


ARMA2 


C30 


D14 
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D29 


C14 








rViviVl UJ 1 


1 J / 


G3 


AT?Ayrr>'^n 

/\rviViL/ju 


H^7 


G4 






D2 




Fr^6 


F3 






D3 


/\rvlVIL/ZO 


rri7 


F4 
I 


AKIVILJZJ 




D1 








A 1? AAFlO 
AKiVlUZJ 




A4 


AKIVIUZZ 


vJD o 




AKiVl UZ I 




R^ 


A T?A/f rion 






AlvlViU 1 V 




A5 


AxvlVlJU 1 o 




D7 


A T? A/rr» 1 7 




B6 


AlvlVlL/ 1 O 


F^7 


C7 


A P AyTH 1 ^ 
AlviVlL' 1 J 




A6 


ArviVlL/ ] H- 




D8 


AKlViU i D 




R7 


A p A/f n 1 7 

AlvlVliJ 1 Z 




C8 


A P A AFi 1 1 
ArClVlU 1 i 




A7 


AP A/TTM n 




n9 


APAyfT^Q 




B8 


AKlVlUo 


A^^ 


A8 


APAyrr*7 

AKlVlU / 




r9 


A PAyfn^ 




RQ 


APAyTFi^ 




mo 




A^A 


AQ 


A P A/TF*^ 




RIO 


APA/TT^O 


I^jZ 


no 


ARMDl 


C32 


Dll 


ARMDO 


D31 


AlO 








ARMnWE 


A30 


B13 


ARMnOE 


C29 


D15 


ARMnCS4 


A29 


A13 


ARMnCSS 


B29 


C15 


ARMRDY 


B28 


B14 
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Some of the ARM's general purpose I/O pins are also connected to the FPGAs. These 
go through connector CN25 on the board, allowing external devices to be connected to 
them (see also ARM section). See Table 19. 



Table 19 



SAIO bus 


ARM GPI/0 


Master 


Slave 


(ARMGPIO) 


pins 


FPGA pin 


FPGA pin 


SATOlO 


23 


B9 


B34 


SAI09 


22 


DIO 


C33 


SAI08 


21 


A9 


A34 


SAI07 


20 


CIO 


D32 


SAT06 


19 


BIO 


B33 


SAI05 


18 


Dll 


C32 


SAI04 


17 


AlO 


D31 


SAT03 


11 


Cll 


A33 


SAI02 


10 


B11 


C31 


SAI01 


1 


C12 


B32 


1 SATOO 


0 


All 


B31 



CPLD Interfacing 

10 Listed in Table 20 are the pins used for setting the Flash Bus Master signal and 
FP COMs. Refer to the CPLD section for greater detail on this. 



Table 20 




Bus Master pin 


C17 


C26 


FP_COM pins 


B16, E17, A15 


B26, C27, A27 


[MSB..LSB] 







15 
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Local I/O devices available to each FPGA 



ATA port 

33 FPGA VO pins directly connect to the ATA port. These pins have lOOQ series 
termination resistors which make the port 5V 10 tolerant. These pins may also be used 
as VO if the ATA port isn't required. See Table 21 . 



Table 21 



ATA line no. 


ATA port 


Master FPGA 


Slave FPGA pin 


ATAO 


1 


' AV4 


AT33 


ATAl 


4 


AU6 


AW36 


ATA2 


3 


AW4 


AU33 


ATA3 


6 


AT7 


AV35 


ATA4 


5 


AW5 


AT32 


ATA5 


8 


AU7 


AW35 


ATA6 


7 


AV6 


AU32 


ATA7 


10 


ATS 


AV34 


ATA8 


9 


AW6 


AV32 


ATA9 


12 


AU8 


AW34 


ATAIO 


11 


AV7 


AT31 


ATAll 


14 


AT9 


AU31 


ATA12 


13 


AW7 


AV33 


ATAl 3 


16 


AV8 


AT30 


ATA14 


15 


AU9 


AW33 


ATA15 


18 


AW8 


AU30 


ATAl 6 


17 


ATIO 


AW32 


ATAl 7 


20 


AV9 


AT29 


ATAl 8 


21 


AUlO 


AV31 


ATA19 


23 


AW9 


AU29 


ATA20 


25 


ATll 


AW31 


ATA21 


28 


AVIO 


AV29 


ATA22 


27 


AUll 


AV30 


ATA23 


29 


AWIO 


AU28 


ATA24 


31 


AU12 


AW30 


ATA25 


32 


AVll 


AT27 


ATA26 


33 


ATI 3 


AW29 




O A 


A XI 7 1 1 
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ATA28 


35 


AU13 


AU27 


ATA29 


36 


ATI 4 


AW28 


ATA30 


37 


AV12 


AT26 


ATA31 


38 


AU14 


AV27 


ATA32 


39 


AW12 


AU26 


GND 


2,19,22, 24, 26, 30,40 



Parallel port 

5 A conventional 25pin D-type connector and a 26way box header are provided to access 
this port. The I/O pins have lOOQ series termination resistors which also make the port 
5V I/O tolerant. These pins may also be used as I/O if the parallel port isn't required. 
See Table 22. See also Appendix C. 



10 



Table 22 



PP line no. 


Parallel port pin 


Master FPGA pin 


Slave FPGA pin 


PPOO 


1 


A8 


A35 


PPOl 


14 


B8 


C34 


PP02 


2 


D9 


B35 


PP03 


15 


A7 


D34 


PP04 


3 


C8 


A36 


PP05 


16 


B7 


C35 


PP06 


4 


D8 


B36 


PP07 


17 


A6 


D35 


PP08 


5 


C7 


F37 


PP09 


6 


B6 


B37 


PPOlO 


7 


D7 


C38 


PPOll 


8 


A5 


E37 


PPOl 2 


9 


C6 


D37 


PPOl 3 


10 


B5 


F36 


PP014 


11 


D6 


D38 


PP015 


12 


A4 


D39 


PPOl 6 


13 


C5 


G36 



GND 



18,19,20,21,22,23,24,25 
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Serial port 

A standard 9pin D-type connector with a RS232 level shifter is provided. This port may 
be directly connected to a PC with a Null Modem cable. A box header with 5 V tolerant 
I/O is also provided. These signals must NOT be connected to a standard RS232 
interface without an external level shifter as the FPGAs may be damaged. See Table 
23. 



Table 23 



Serial line no. 


Serial port pin no. 


Master FPGA pin 


Slave FPGA pin 


Serial 0 (CTS) 


8 (CTS) 


AV3 


AT34 


Serial 1 (RxD) 


2 (RxD) 


AU4 


AU36 


Serial 2 (RTS) 


7 (RTS) 


AV5 


AU34 


Serial 3 fTxD) 


3 (TxD) 


AT6 


AV36 




GND 


5 


Not connected 


1,4,6,9 



Serial Header 

Each FPGA also connects to a 10 pin header (CN9/CN16). The connections are shown 
in Table 24: 



Table 24 



(CN9/CN16) 


Master 


Slave 


Header pin no. 


FPGA pin 


FPGA pin 


1 


D1 


E38 


2 


F4 


G37 


3 


D3 


E39 


4 


F3 


H36 
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5 


D2 


F38 


6 


G4 


H37 


7 


03 


F39 



8.9 


GND 


10 


+5V 



Shared I/O Devices 

5 These devices are shared directly between the two FPGAs and great care should be 
taken as to which FPGA accesses which device at any given time. 

VGA Monitor 

10 A standard 1 Spin High Density connector with an on-board 4bit DAC for each colour 
(Red, Green, Blue) is provided. This is connected to the FPGAs as set forth in Table 25: 



Table 25 



VGA line 


Master FPGA pin 


Slave FPGA pin 


VGAll fR3) 


AV25 


ATI 6 


VGAIO (K2.) 


AT24 


AW14 


VGA9 fRl) 


AW25 


AU16 


VGA8 rRO) 


AU24 


AV15 


VGA? (G3) 


AW24 


AR17 


VGA6 f G2^ 


AW23 


AW15 


VGA5 (Gl) 


AV24 


ATI 7 


VGA4 (GO) 


AV22 


AU17 


VGA3 fB3) 


AR23 


AVI 6 


VGA2 (B2) 


AW22 


AR18 


VGAl CBn 


AT23 


AW16 


VGAO fBO) 


AV21 


ATI 8 


VGAl 3 


AW26 


AW13 


VGAl 2 


AU25 


AV14 
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LEDs 

Eight of the twelve LEDs on the board are connected directly to the FPGAs. See Table 
26. 



Table 26 



LED 


Master FPGA pin 


Slave FPGA pin 


D5 


AT25 


AU15 


D6 


AV26 


AVI 3 


D7 


AW27 


ATI 5 


D8 


AU26 


AW12 


D9 


AV27 


AU14 


DIO 


AT26 


AV12 


Dll 


AW28 


ATI 4 


D12 


AU27 


AU13 



GPIO connector 

A 50way Box header with 5V tolerant I/O is provided. 32 data bits ('E' bus) are 
available and two clock signals. The connector may be used to implement a SelectLink 
to another FPGA. +3V3 and +5V power suppUes are provided via fuses. See Table 27. 



Table 27 



Expansion 


GPI/0 


Master 


Slave FPGA 


bus line 


header pin 
no. 


FPGA pin 


pin 


EO 


11 


AT15 


AW27 


E1 


13 


AVI 3 


AV26 


E2 


15 


AU15 


AT25 


E3 


17 


AW13 


AW26 
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E5 


23 


AT16 


AV25 


Ffi 


25 


AW14 


AT24 


F7 


27 


AU16 


AW25 






AVI 5 


AU24 


FQ 




AR17 


AW24 


F1 0 


3S 


AW15 


AW23 


F1 1 


37 


ATI? 


AV24 


F17 


41 


AU17 


AV22 


F1 ^ 


43 


AV16 


AR23 




45 


AR18 


AW22 


F1 ^ 


47 




AT23 


F1 ^ 


44 


ATI 8 


AV21 

£\. V Z, 1 


F17 


49 


AVI 7 


AU23 


Fl R 

J_/l o 


40 




AW21 


FIO 


38 


AW17 


AV23 


F?n 


34 


ATI 9 


AR22 


F71 


32 


AV18 


AV20 


F99 


30 


AU19 


AW20 


F71 


28 


AW18 


AVI 9 


F94 


24 


AU21 


AU21 


E25 


22 


AV19 


AW18 


E26 


20 


AW20 


AU19 


E27 


18 


AV20 


AV18 


£28 


14 


AR22 


AT19 


E29 


12 


AV23 


AW17 


E30 


10 


AW21 


AU18 


E31 


8 


AU23 


AV17 




CLKA 


5 fCLK 3 on diagrams') 


CLKB 


49 ( CLK 4 on diaerams') 


+5V 


1.2 


+3V3 


3.4 


GND 


6, 7, 9, 16,19, 26, 29, 36, 39, 46, 48, 50 



SelectLink Interface 
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There is another 32bit general purpose bus connecting the two FPGAs which may be 
used to implement a SelectLink interface to provide greater bandwidth between the two 
devices. The connections are set forth in Table 28: 



Table 28 



SelectLink Line 


Master 


Slave 




FPGA pin 


FPGA pin 


oLU 




AVV 1 1 


CI d 

oL 1 


A\A/OQ 


ATI ^5 

Alio 


CI o 

oLz 


A TOT 
A 1 Zf 


AVI 1 


oLo 


A\ A/on 


A I M O 


CI A 

oL4 


A 1 lOQ 


AXAZ-I n 

AvVlu 


CI 


A\/Qn 
AVoU 


A 1 M ^ 

AU 1 1 


CI £5 
OLD 


A\ /OQ 

AVzy 


AV I U 


CI T 

oL/ 


AVvol 


AT-1 < 

Am 


CI Q 

oLo 


Al lOQ 

Au^y 


Avvy 


CI Q 

oLy 


Avon 


A 1 M n 
AUIU 


CI -in 
oLIU 


A Ton 

A i2y 


AVy 


CI i ^ 

oL1 1 


A\ A/QO 

AVVoz 


ATH n 
AMU 


CI ^ o 


Al IQH 

AUoU 


A\A/Q 

AVvd 


CI i Q 


AvvOO 


Al IQ 

Auy 


SL14 


AT30 


AV8 


SL15 


AV33 


AW7 


SL16 


AU31 


AT9 


SL17 


AT31 


AV7 


SL18 


AW34 


AU8 


SL19 


AV32 


AW6 


SL20 


AV34 


AT8 


SL21 


AU32 


AV6 


SL22 


AW35 


AU7 


SL23 


AT32 


AU8 


SL24 


AV35 


AT7 


SL25 


AU33 


AW4 


SL26 


AW36 


AU6 


SL27 


AT33 


AV4 


SL28 


AV36 


AT6 


SL29 


AU34 


AV5 


SL30 


AU36 


AU4 
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SL31 



AT34 



AV3 



USB 

The FPGAs have shared access to the USB chip on the board. As in the case of the 
Flash RAM, the FPGA needs to notify the CPLD that it has taken control of the USB 
chip by setting the USBMaster pin low before accessing the chip. For more information 
on the USB chip refer to the USB section of this document. 



Table 29 




USBMaster 


D17 


D26 


USBMS 


C16 


D27 


nRST 


B15 


B27 


IRQ 


D16 


C28 


AO 


A14 


A28 


nRD 


B14 


B28 


nWR 


C15 


B29 


nCS 


A13 


A29 


D7 


D15 


C29 


D6 


B13 


A30 


D5 


C14 


D29 


D4 


A12 


B30 


D3 


D14 


C30 


D2 


C13 


A31 


Dl 


B12 


D30 


DO 


D13 


A32 



CPLD 

The board is fitted with a Xilinx XC95288XL CPLD which provides a number of Glue 
Logic functions for shared RAM arbitration, interfacing between the ARM and FPGA 
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and configuration of the FPGAs. The later can be used to either configure the FPGAs 
from power up or when one FPGA re-configures the other (Refer to section 
Programming the FPGAs'). A full listing of ABEL code contained in the CPLD can be 
found in Appendix D. 

5 

Shared SRAM bank controller 

The CPLD implements a controller to manage the shared RAM banks. A Request - 
Grant system has been implemented to allow each SRAM bank to be accessed by one of 
the three devices. A priority system is employed if more than one device requests the 
10 SRAM bank at the same time. 



Highest priority : ARM 

Master FPGA 
Lowest priority : Slave FPGA 

15 

The FPGAs request access to the shared SRAM by pulling the corresponding 
REQUEST signals low and waiting for the CPLD to pull the GRANT signals low in 
response. Control is relinquished by setting the REQUEST signal high again. The ARM 
processor is able to request access to the shared SRAM banks via some registers within 
20 the CPLD - refer to the next section. 



CPLD Registers for the ARM 



25 



The ARM can access a number of registers in the CPLD, as shown in Table 30: 



Table 30 



0x00 



This is an address indirection register for register 1 which used 
for the data access. 
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0 Write only FLASH Address A0-A7 

1 Write only FLASH Address A8-A1 5 

2 Write only FLASH Address A16-A24 

3 Read / Write FLASH data (Access time must be at least 
150ns) 

14 Backlight brightness 

5 Write Only USB control (RST / MS ) 

DO : USB RESET 

Dl : USB Master Slave 


0x04 


Data for register 0 address expanded data 


0x08 


Master FPGA access 


OxOC 


Slave FPGA access 


0x10 


SRAM Arbiter 

DO: Shared SRAM bank 0 Request ( high to request, low to 
relinquish ) 

Dl : Shared SRAM bank 1 Request ( high to request, low to 
relinquish ) 

D4: Shared SRAM bank 0 Granted ( High Granted Low not 
Granted ) 

D5: Shared SRAM bank 1 Granted ( High Granted Low not 
Granted ) 


0x14 


Status / FPGA control pins ( including PLL control ) 
Write 

DO : Master FPGA nPROGRAM pin 

Dl : Slave FPGA nPROGRAM pin 

D2 : Undefined 

D3 : Undefined 

D4 : PLL Serial clock pin 

D5 : PLL Serial data pin 
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D6 : PLL Feature Clock 




D7 : PLL Internal Clock select 




Read 




DO : Master FPGA DONE Signal 




Dl : Slave FPGA DONE signal 




D2 : FPGA INlfSignal 




D3 : FLASH status Signal 




D4 : Master FPGA DOUT Signal 




D5 : Slave FPGA DOUT Signal 




D6 : USB IRQ Signal 


0x18 


USB Register 0 


OxlC 


USB Register 1 



CPLD Registers for the FPGA 's 

The FPGAs can access the CPLD by setting a command on the FPCOM pins. Data 
transferred on the FPGA (Flash RAM) databus. See Table 31. 

Table 31 



0x0 


Write to Control Register 




DO : Master FPGA Program signal ( inverted) 




Dl : Slave FPGA Program signal (inverted) 




D2 : Master FPGA chip select signal (inverted) 




D3 : Slave FPGA chip select signal (inverted) 


0x3 


Sets configuration clock low 
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0x5 


Read Status Register 

DO : Master FPGA DONE signal 
Dl : Slave FPGA DONE signal 
D2 : FPGA INIT signal 
D3 : FLASH status signal 
D4 : Master FPGA DOUT signal 
D5 : Slave FPGA DOUT signal 
D6 : USB IRQ signal 


0x7 


No Operation 



These commands will mainly be used when one FPGA reconfigures the other. Refer to 
the FPGA configuration section and the appropriate Xilinx datasheets for more 
information. 

CPLDLEDs 

Four LED's are directly connected to the CPLD. These are used to indicate the 
following: 

DO DONE LED for the Master FPGA Flashes during programming 
Dl DONE LED for the Slave FPGA Flashes during programming 
D2 Not used 

D3 Flashes until an FPGA becomes programmed 
Other Devices 
USB 

The board has a SCAN Logic SLl IH USB interface chip, capable of full speed 
20 12Mbits/s transmission. The chip is directly connected to the FPGAs and can be 
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accessed by the ARM processor via the CLPD (refer to the CPLD section of this 
document for further information). 

The datasheet for this chip is available at http://www.scanloRicxom/pdf'sll Ih 
/slllhspec.pdf 

5 

PSU 

This board maybe powered from an external 12V DC power supply through the 2.1mm 
DC JACK. The supply should be capable of providing at least 2.4A. 

10 

Handel-C Library Reference 

hitroduction 

This section describes the Handel-C libraries written for the board. The kUb.h library 
15 provides a number of macro procedures to allow easier access to the various devices on 
the board, including the shared memory, the Flash RAM, the CPLD and the LEDs. Two 
other libraries are also presented, parallel_port.h and serialjport.h, which are generic 
Handel-C libraries for accessing the parallel and serial ports and communicating over 
these with extemal devices such as a host PC. 

20 

Also described is an example program which utiUzes these various libraries to 
implement an echo server for the parallel and serial ports. 

Also described here is a host side implementation of ESL's parallel port data transfer 
25 protocol, to be used with the data transfer macros in parallel_port.h. 

The klib.h Library 
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Shared RAM arbitration 

A request - grant mechanism is implemented to arbitrate the shared RAM between the 
two FPGAs and the ARM processor. Four macros are provided to make the process of 
5 requesting and releasing the individual RAM banks easier. 

KRequestMemoryBankOQ; 
KRequestMemoryBankl (); 
KReleaseMemoryBankOQ; 
10 KReleaseMemoryBankl (); 

Arguments 

None. 

15 Return Values 

None. 

Execution Time 

KRequestMemoryBank#() requires at least one clock cycle. 
20 KReleaseMemoryBank#() takes one clock cycle. 

Description 

These macro procedures will request and relinquish ownership of their respective 
memory banks. When a request for a memory bank is made the procedure will block the 
25 thread until access to the requested bank has been granted. 

Note: The request and release functions for different banks may be called in 
parallel with each other to gain access to or release both banks in the same cycle. 
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Flash RAM Macros 

These macros are provided as a basis through which interfacing to the Flash RAM can 
be carried out. The macros retrieve model and status information from the RAM to 
5 illustrate how the read/write cycle should work. Writing actual data to the Flash RAM is 
more complex and the implementation of this is left to the developer. 

KSetFPGAFBMQ 
KReleaseFPGAFBMQ 

10 

Arguments 

None. 

Return Values 

15 None. 

Execution Time 

Both macros require one clock cycle. 
20 Description 

Before any communication with the Flash RAM is carried out the FPGA needs to let the 
CPLD know that it is taking control of the Flash RAM. This causes the CLPD to tri- 
state the Flash bus pins, avoiding resource contention. KSetFPGAFBMQ sets the Flash 
Bus Master (FBM) signal and KReleaseFPGAFBM() releases it. This macro is 
25 generally called by higher level macros such as KReadFlashQ or KWriteFlashQ. 

Note: These two procedures access the same signals and should NOT be called in 
parallel to each other. 
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KEnableFlashQ 
KDisableFlashQ 

Arguments 

5 None. 

Return Values 

None. 

10 Execution Time 

Both macros require one clock cycle. 

Description 

These macros raise and lower the chip-select signal of the Flash RAM and tri-state the 
15 FPGA Flash RAM lines (data bus, address bus and control signals). This is necessary if 
the Flash RAM is to be shared between the two FPGAs as only one chip can control the 
Flash at any give time. Both FPGAs trying to access the Flash RAM simultaneously can 
cause the FPGAs to 'latch up' or seriously damage the FPGAs or Flash RAM chip. This 
macro is generally called by higher level macros such as KReadFlashQ or 
20 KWriteFlashQ. 

Note: These macros access the same signals and should NOT be called in parallel 
with each other. 

25 KWriteFlash(address, data) 

KReadFlash(address, data) 

Arguments 

24 bit address to be written or read. 
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8 bit data byte. 
Return Values 

KReadFlashO returns the value of the location specified by address in the data 
5 parameter. 

Execution Time 

Both procedures take 4 cycles. 

10 The procedures are limited by the timing characteristics of the Flash RAM device. A 
read cycle takes at least 120ns, a write cycle 100ns. The procedures have been set up for 
aHandel-C clock of 25MHz. 

Description 

15 The macros read data from and write data to the address location specified in the 
address parameter. 

Note: These macros access the same signals and should NOT be called in parallel 
with each other. 

20 

KSetFlashAddress(address) 

Arguments 

24 bit address value. 

25 

Return Values 

None. 

Execution Time 
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This macro requires one clock cycle. 
Description 

The macro sets the Flash address bus to the value passed in the address parameter. This 
macro is used when a return value of the data at the specified location is not required, as 
may be the case when one FPGA is configuring the other with data from the Flash 
RAM since the configuration pins of the FPGAs are connected directly to the lower 8 
data lines of the Flash RAM. 

KReadFlashlDfflashjcomponentJD, manufacturer JD) 
KReadFlashStatus(status) 

Arguments 

8 bit parameters to hold manufacturer, component and status information. 
Return Values 

The macros retum the requested values in the parameters passed to it. 
Execution Time 

KReadFlashStatusQ requires 10 cycles, 
KReadFlashlDO requires 14 cycles. 

Description 

The macros retrieve component and status information from the Flash RAM. This is 
done by performing a series of writes and reads to the internal Flash RAM state 
machine. 
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Again, these macros are limited by the access time of the Flash RAM and the number of 
cycles required depends on rate the design is clocked at. These macros are designed to 
be used with a Handel-C clock rate of 25MHz or less. 



5 Although a system is in place for indicating to the CPLD that the Flash RAM is in use 
(by using the KSetFPGAFBMQ and KReleaseFPGAFSMQ macros) it is left up to the 
developers to devise a method of arbitration between the two FPGAs. As all the Flash 
RAM Hues are shared between the FPGAs and there is no switching mechanism as in 
the shared RAM problems will arise if both FPGAs attempt to access the Flash RAM 

10 simultaneously. 

Note: These macros access the same signals and should NOT be called in parallel with 
each other. Also note that these macros provide a basic interface for conamunication 
with the Flash RAM, For more in-depth please refer to the Flash RAM datasheet. 

15 

CPLD Interfacing 



The following are macros for reading and writing to the CPLD status and control 
registers: 

20 

KReadCPLDStatus(status) 
KWriteCPLDControl(control) 



Arguments 

25 8 bit word 



Return Values 

KReadStatusO returns an 8 bit word containing the bits of the CPLD's status register. 
(Refer to the CPLD section for more information) 
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Execution Time 

Both macros require six clock cycles, at a Handel-C clock rate of 25MHz or less. 
5 Description 

These macros read the status register and write to the control register of the CPLD. 
KSetFPCOMtfpj^ommand) 

10 Arguments 

3 bit word. 

Return Values 

None. 

15 

Execution Time 

This macro requires three clock cycles, at a Handel-C clock rate of 25MHz or less. 
Description 

20 This macro is provided to make the sending of FP_COMMANDs to the CPLD easier. 
FP COMMANDs are used when the reconfiguration of one FPGA from the other is 
desired (refer to the CPLD section for more information). 

The different possible fp_conunand (s) are set forth in Table 32: 

25 

Table 32 

FP_SET_IDLE Sets CPLD to idle 

FPREADSTATUS Read the status register of the CPLD 

FP WRITE CONTROL Write to the control register of the CPLD 
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FP CCLK HIGH 



FP CCLK LOW 



Set the configuration clock low 
Set the configuration clock high 



e.g. 



5 



KSetFPCOM(FP__READ_STATUS); 
KSetFPCOM(FP_SET_IDLE); 



Note: These macros access the same signals and should NOT be called in parallel 
with each other. 



Arguments 

15 8 bit word. 

Return Values 

None, 

20 Execution Time 

One clock cycle. 

Description 

This macro procedure has been provided for controlling the LEDs on the board. The 
25 maskByte parameter is applied to the LEDs on the board, with a 1 indicating to turn a 
hght on and a 0 to turn it off. The MSB of maskByte corresponds to D12 and the LSB 
to D5 on the board. 



10 LEDs 



KSetLEDs(maskByte) 
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Note: Only one of the FPGAs may access this function. If both attempt to do so 
the FPGAs will drive against each other and may 'latch-up', possibly damaging 
them. 

5 

Using the Parallel Port 
Introduction 

10 The library parallel jport.h contains routines for accessing the parallel port. This 

implements a parallel port controller as an independent process, modeled closely on the 
parallel port interface found on an IBM PC. The controller allows simultaneous access 
to the control, status and data ports (as defined on an IBM PC) of the parallel interface. 
These ports are accessed by reading and writing to channels into the controller process. 

15 The reads and writes to these channels are encapsulated in other macro procedures to 
provide an intuitive API. 

Figure 11 shows a structure of a Parallel Port Data Transmission System 1100 
according to an embodiment of the present invention. An implementation of ESL's 

20 parallel data transfer protocol has also been provided, allowing data transfer over the 
parallel port, to and from a host computer 1102. This is implemented as a separate 
process which utilizes the parallel port controller layer to implement the protocol. Data 
can be traasferred to and fi^om the host by writing and reading from channels into this 
process. Again macro procedure abstractions are provided to make the API more 

25 intuitive. 

A host side application for data transfer under Windows95/98 and NT is provided. Data 
transfer speeds of around 100 Kbytes/s can be achieved over this interface, limited by 
the speed of the parallel port. 
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Accessing the parallel port directly. 

The 17 used pins of the port have been split into data, control and status ports as defined 
in the IBM PC parallel port specification. See Table 33. 

Table 33 



Port Name 


Pin number 


Data Port 




DataO 


2 


Data 1 


3 


Data 2 


4 


Data 3 


5 


Data 4 


6 


Data 5 


7 


Data 6 


8 


Data? 


9 






Status Port 




nACK 


10 


Busy 


11 


Paper Empty 


12 


Select 


13 


n Error 


15 






Control Port 




nStrobe 


1 


nAutoFeed 


14 


Initialise Printer 


16 
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(Init) 




nSelectIn 


17 



The parallel port controller process needs to be run in parallel with those part of the 
program wishing to access the parallel port. It is recommended that this is done using a 
par{} statement in the main() procedure. 

5 

The controller procedure is: 

parallel j?ort( pp_data_send_channel, 
pp_dataj'ead_channel, 
10 pp_control _port_read, 

pp_status _portj'ead, 
pp_status_portjwrite); 

where the parameters are all channels through which the various ports can be accessed. 

15 

Parallel Port Macros 

It is recommended that the following macros be used to access the parallel port rather 
than writing to the channels directly. 

20 

PpWriteData(byte) 
PpReadData (byte) 

Arguments 

25 Unsigned 8 bit word. 

Return Values 
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PpReadDataQ returns the value of the data pins in the argument byte. 
Execution Time 

Both macros require one clock cycle. 

5 

Description 

These write the argument byte to the register controlling the data pins of the port, or 
return the value of the data port within the argument byte respectively, with the MSB 
of the argument corresponding to data[7]. Whether or not the value is actually placed on 
10 the data pins depends on the direction settings of the data pins, controlled by bit 6 of the 
status register. 

PpReadControl( control _port) 

15 Arguments 

Unsigned 4 bit word. 

Return Values 

PpReadControlQ returns the value of the control port pins in the argument byte. 

20 

Execution Time 

This macro requires one clock cycle. 
Description 

25 This procedure returns the value of the control port. The 4 bit nibble is made up of 
[nSelect Jn @ Init @ nAutofeed @ nStrobe], where nSelectJn is the MSB. 

PpReadStatus(status j)ort) 
PpSet Status (status _port) 
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Arguments 

Unsigned 6 bit word. 

5 Return Values 

PpReadStatusO returns the value of the status port register in the argument byte. 

Execution Time 

This macro requires one clock cycle. 

10 

Description 

These read and write to the status port. The 6 bit word passed to the macros is made up 
of [pp_direction @ busy @ nAck @ PE @ Select @ nError], where pp_direction 
indicates the direction of the data pins (i.e. whether they are in send [1] or receive [0] 
15 mode). It is important that this bit is set correctly before trying to write or read data 
from the port using PpWriteData() or PpReadDataQ. 

Note; All of the ports may be accessed simultaneously, but only one operation 
may be performed on each at any given time. Calls dealing with a particular port 
20 should not be made in parallel with each other. 

Transferring data to and from the host PC 

The library parallel j?ort,h also contains routines for transferring data to and from a 
25 host PC using ESL's data transfer protocol. The data transfer process, pp^comsQ, which 
implements the transfer protocol should to be run in parallel to the parallel port 
controller process, again preferably in the main par{} statement. A host side 
implementation of the protocol, ksend.exe, is provided also. 
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ppjcoms (pp_send_chan, 



pp_recv_chan, 

ppjcommand, 

pp_error) 



- channel to write data to when sending 

- channel to read data from when receiving 

- channel to write commands to 

- channel to receive error messaged from. 



The following macros provide interfaces to the data transfer process: 



OpenPP(error) 
ClosePP(error) 



- open the parallel port for data transfer 

- close the port 



Note: Make sure that the host side application, ksend.exe, is running. The macros 
will try and handshake with the host and will block (or timeout) until a response is 
received. Also note that the following macros all access the same process and 
should NOT be called in parallel with each other. 

Arguments 

Unsigned 2 bit word. 

Return Values 

The argument will return an error code indicating the success or failure of the 
command. 

Execution Time 

This macro requires one clock cycle. 
Description 

These two macros open and close the port for receiving or sending data. They initiate a 
handshaking procedure to start conmiunications with the host computer. 
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SetSendMode(error) - set the port to send mode 
SetRecvMode(error) ~ set the port to receive mode 

Arguments 

5 Unsigned 2 bit word. 

Return Values 

The argument will return an error code indicating the success or failure of the 
command. 

10 

Execution Time 

This macro requires one clock cycle. 
Description 

15 These set the direction of data transfer and the appropriate mode should be set before 
attempting to send or receive data over the port. 

SendPPfbyte, error) - send a byte over the port 
ReadPP(byte, error) - read a byte from the port 

20 

Arguments 

Unsigned 8 bit and unsigned 2 bit words. 
Return Values 

25 ReadPPO returns the 8 bit data value read from the host in the byte parameter. 

Both macros will return an error code indicating the success or failure of the command. 

Execution Time 
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How quickly these macros execute depend on the Host. The whole sequence of 
handshaking actions for each byte need to be completed before the next byte can be 
read or written. 

5 Description 

These two macros will send and receive a byte over the parallel port once this has been 
initialized and placed in the correct mode. 

The procedures return a two bit error code indicating the result of the operation. These 
10 codes are defined as: 

#defme PP_NO„ERROR 0 
#define PP_HOST_BUFFER__NOT__FINISHED 1 
#defme PP_OPEN_TIMEOUT 2 

15 

Note: SendPP and ReadPP will block the thread until a byte is transmitted or the 
timeout value is reached. If you need to do some processing while waiting for a 
communication use a 'prialt' statement to read from the global pp_recv_chan 
channel or write to the pp_send_chan channel. 

20 

Typical macro procedure calls during Read / Write 

Figure 12 is a flowchart that shows the typical series of procedure calls 1200 when 
receiving data. Figure 13 is a flow diagram depicting the typical series of procedure 
25 calls 1300 when transmitting data. 

The Ksend application 
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The ksend.exe application is designed to transfer data to and from the board FPGAs 
over the parallel port. It implements the ESL data transfer protocol It is designed to 
communicate with the pp^comsQ process running on the FPGA. This application is still 
in the development stage and may have a number of bugs in it. 

5 

Two versions of the program exist, one for Windows95/98 and one for WindowsNT. 
The NT version requires the GenPort driver to be installed. Refer to the GenPort 
documentation for details of how to do this. 

10 In its current for the ksend application is mainly intended for sending data to the board, 
as is done in the esl_boardtest program. It is how ever also able to accept output form 
the board. Again, please refer to the appHcation note or the ksend help (invoked by 
calling ksend without any parameters) for further details. 

15 Serial Port 

Introduction 

Each FPGA has access to a RS232 port allowing it to be connected to a host PC. A 
20 driver for transferring data to and from the FPGAs from over the serial port is contained 
in the file serialjport.h. 

RS232A Interface 

There are numerous ways of implementing RS232 interfacing, depending on the 
25 capabilities of the host and device and what cables are used. This interface is 

implemented for a cross wired null modem cable which doesn't require any hardware 
handshaking - the option of software flow control is provided, though this probably 
won't be necessary as the FPGA will be able to deal with the data at a much faster rate 
than the host PC can provide it. When soft flow control is used the host can stop and 
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start the FPGA transmitting data by sending the XON and XOFF tokens. This is only 
necessary when deaUng with buffers that can fill up and either side needs to be notified. 

Serial port macros 

5 

Serial port communications have been implemented as a separate process that runs in 
parallel to the processes that wish to send/ receive data. Figure 14 is a flow diagram 
illustrating several processes 1402, 1404 running in parallel. 

1 0 The serial port controller process is 

serial _port(spJnput, spjoutput); 

where sp Jnput and sp_output are n bit channels through which data can be read or 
15 written out form the port. These reads and writes are again encapsulated in separate 
macro procedures to provide the user with a more intuitive API 

SpReadData(byte) - read a data byte from the port 
SpWriteData(byte) - write a byte to the port 

20 

Arguments 

n bit words, where n is the number of data bits specified. 
Return Values 

25 SpReadDataQ returns an n bit value corresponding to the transmitted byte in the 
argument. 

Execution Time 

The execution time depends to the protocol and the baud rate being used. 
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Description 

These procedures send and receive data over the serial port using the RS232 protocol. 
The exact communications protocol must be set up using a series of #defines before 
5 including the serial_port.h library. To use an 8 data bit, 1 start and 1 stop bit protocol at 
11 5200 baud on a null modem cable with no flow control the settings would be: 



10 



#define BAUD_RATE 115200 
#define START_BIT ((unsigned 1)0) 

#def ine STOP_BIT ( (unsigned 1) 1) 

#define NUM DATA BITS 8 



Other options are: 

For soft flow control: 
15 #define SOFTFLOW 

#define XON 
#define XOFF 



<ASCII CHARACTER CODE> 
<ASCII CHARACTER CODE> 



20 



RTS/CTS flow control: 

#define HARDFLOW 



The default settings are: 

Baud rate 9600 

Start bit 0 

25 Stop bit 1 

Num. data bits 8 

XON 17 

XOFF 19 
Flow control off 
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Any of the standard baud rate settings will work provided that the Handel-C clock rate 
is at least 8 times higher than the baud rate. Also ensure that the macro CLOCK_RATE 
is defined, this is generally found in the pin definition header for each of the FPGAs. 

e .g. 

#define CLOCK__RATE 25000000 // define the 
clock rate 

Example Program 

Shown here is an example Handel-C program that illustrates how to use the parallel and 
serial port routines found in the serial_port.h and paralleljort.h libraries. The program 
implements a simple echo server on the serial and parallel ports. The SetLEDsQ 
function fi*om the klib.h library is used to display the ASCII value received over the 
serial port on the LEDs in binary. 

// Include the necessary header files 
#define MASTER 
#ifdef MASTER 

#include "KompressorMaster .h" 
#else 

#include "KompressorSlave . h" 
#endif 

#include "stdlib.h" 
#include "parallel_port .h" 
#include "klib.h" 

// Define the protocol and include the file 
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10 



#define BAUD_RATE 9600 
#define NUM_DATA_BITS 8 
#define NULLMODEM 
#include "serial_port .h" 

llllllllllllltllllllllllllllllllll 

II Process to echo any data received by the parallel 
port 

1 1 to verify it is working properly 



macro proc EchoPP{) 

{ 

unsigned 8 pp_data_in; 

unsigned 2 error with {warn = o}; 

15 unsigned 1 done; 

OpenPP (error) ; // initiate contact with host 
while ( [done) 

{ 

20 // read a byte 

SetRecvMode (error) ; 
ReadPP (pp_data_in, error) ; 

/ / echo it 
25 SetSendMode (error) ; 

WritePP (pp_data_in, error) ; 

} 

ClosePP (error) ; // close connection 
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////////////////////////////////// 

/ / Process to echo any data received by the serial 
port 

5 //to verify it is working properly. We are always 

// listening on the serial port so there is no need 
to open it . 

macro proc EchoSPO 
10 { 

unsigned 8 serial_in_data; 



while (1) 
{ 

15 SpReadData (serial_in_data) ; // read a byte 

from the serial port 

SetLEDs (serial_in_data) ; 

SpWriteData (serial_in__data) ; // write it 

back out 
20 } 

delay; // avoid combinational cycles 

} 

void main (void) 

{ 

25 while (1) 

{ 

par 

{ 

EchoPPO; //Parallel port thread 
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EchoSPO; // Serial port thread 



1 1 1 1 1 1 Start the services 1 1 1 1 1 1 1 1 
f I Parallel Port stuff 
5 pp_coms (pp___send_chan, pp_recv_chan, 

pp_command, pp_error) ; 

parallel_port (pp_data_send__channel , 
pp__data_read_channel , 
10 pp_control_port_read , 

pp_status_port_read, pp__status_port_write) ; 

// Serial port stuff // 
serial_port (sp_input, sp_output) ; 

15 

} 
} 



20 The code can be compiled for either FPGA by simple defining or un-defining the 
MASTER macro - lines 1 to 5 



More Information 



25 Useful information pertaining to the subjects of this described herein can be foxmd in 
the following: The Programmable Logic Data Book, Xilinx 1996; Handel-C 
Preprocessor Reference Manual, Handel-C Compiler Reference Manual, and Handel-C 
Language Reference Manual, Embedded Solutions Limited 1998; and Xilinx Datasheets 
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and Application notes, available from the Xilinx website http ://www.xilinx . com, and 
which are herein incorporated by reference. 

Illustrative Embodiment 

5 

According to an embodiment of the present invention, a device encapsulates the 
Creative MP3 encoder engine in to an FPGA device. Figure 15 is a block diagram of an 
FPGA device 1500 according to an exemplary embodiment of the present invention. 
The purpose of the device is to stream audio data directly from a CD 1502 or CDRW 
10 into the FPGA, compress the data, and push the data to a USB host 1504 which delivers 
it to the OASIS(Nomad 2) decoder. The entire operation of this device is independent 
of a PC. 

The design of the FPGA uses the "Handel-C" compiler, described above, from 
15 Embedded Solutions Limited (ESL). The EDA tool provided by ESL is intended to 
rapidly deploy and modify software algorithms through the use of FPGAs without the 
need to redevelop silicon. Therefore the ESL tools can be utihzed as an alternative to 
siUcon development and can be used in a broader range of products. 

20 Feature Overview 

The FGPA preferably contains the necessary logic for the following: 

- MP3 Encoder 1506 

- User Command Look Up Table 
25 - play 

- pause 

- eject 

- stop 

- skip song (forward / reverse) 



EMB1P022 



-93- 



- scan song (forward / reverse) 

- record (rip to MPS) -> OASIS Unit 

- ATAPI 

- command and control 

- command FIFO 

- data bus 

- command bus 

- (2) 64 sample FIFOs (1 6bit * 44. 100 kHz) 

- Serial Port (1 6550 UART) optionally EEPROM Interface (I2C & I2S) 

- USB Interface to host controller 

- SDRAM controller 

- 32-bit ARM or RISC processor 

In addition to the FPGA the following is preferably provided: 

- USB Host / Hub controller (2 USB ports) 

- 4MB SDRAM 

- 128K EEPROM 

- 9-pin serial port 

- 6 control buttons. 

- 40-Pin IDE hiterface for CD or CDRW 
Interfaces 

ATAPI (IDE) Interface 
User Interface 
USB hiterface 
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Network-Based Configuration 

Figure 16 illustrates a process 1600 for network-based configuration of a programmable 
logic device. In operation 1602, a default application is initiated on a programmable 

5 logic device. In operation 1604, a file request for configuration data fi*om the logic 
device is sent to a server located remotely firom the logic device utilizing a network. 
The configuration data is received fi-om the network server in operation 1606, and can 
be in the form of a bitfile for example. In operation 1608, the configuration data is used 
to configure the logic device to run a second application. The second application is run 

10 on the logic device in operation 1610. 

According to one embodiment of the present invention, the logic device includes one or 
more Field Programmable Gate Arrays (FPGAs), Preferably, a first FPGA receives the 
configuration data and uses that data to configure a second FPGA. The first and second 
15 FPGAs can be clocked at different speeds. 

According to another embodiment of the present invention, the default application and 
the second application are both able to run simultaneously on the logic device. The 
logic device can fiirther include a display screen, a touch screen, an audio chip, an 
20 Ethernet device, a parallel port, a serial port, a RAM bank, a non-volatile memory, 
and/or other hardware components. 

Figure 17 illustrates a process 1700 for remote altering of a configuration of a hardware 
device. A hardware device is accessed in operation 1702 utilizing a network such as the 
25 Internet, where the hardware device is configured in reconfigurable logic. In operation 
1704, a current configuration of the hardware device is detected prior to selecting 
reconfiguration information. Reconfiguration information is selected in operation 1706, 
and in operation 1708, is sent to the hardware device. In operation 1710, the 
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reconfiguration information is used to reprogram the reconfigurable logic of the 
hardware device for altering a configuration of the hardware device. 

The reconfiguration of the hardware device can be performed in response to a request 
5 received from the hardware device. In an embodiment of the present invention, the 
hardware device is accessed by a system of a manufacturer of the hardware device, a 
vendor of the hardware device, and/or an administrator of the hardware device. 

hi another embodiment of the present invention, the logic device includes at least one 
10 Field Programmable Gate Array (FPGA). Preferably, a first FPGA receives the 

reconfiguration information and uses the reconfiguration information for configuring a 
second FPGA. 



Illustrative Embodiment 

15 

Figure 18 illustrates a process 1800 for processing data and controlling peripheral 
hardware. In operation 1802, a first Field Programmable Gate Array (FPGA) of a 
reconfigurable logic device is initiated. The first FPGA is configured with 
programming functionahty for programming a second FPGA of the logic device in 

20 accordance with reconfiguration data. The reconfiguration data for configuring the 
second FPGA is retrieved in operation 1804. In operation 1806, the first FPGA is 
instructed to utihze the reconfiguration data to program the second FPGA to run an 
appHcation. In operation 1808, the first FPGA is instructed to user the reconfiguration 
data to program the second FPGA to control peripheral hardware incident to running the 

25 application. 



In one embodiment of the present invention, data stored in nonvolatile memory is 
utilized for configuring the first FPGA with the programming functionality upon 
initiation of the first FPGA. In another embodiment of the present invention, the 
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configuration data is retrieved from a server located remotely from the logic device 
utilizing a network. The configuration data can be received in the form of a bitfile. 

The first and second FPGA's can be clocked at different speeds. Preferably, the logic 
5 device also includes a display screen, a touch screen, an audio chip, an Ethernet device, 
a parallel port, a serial port, a RAM bank, and/or a non-volatile memory. 

Further Embodiments and Equivalents 

10 While various embodiments have been described above, it should be understood that 
they have been presented by way of example only, and not limitation. Thus, the breadth 
and scope of a preferred embodiment should not be limited by any of the above 
described exemplary embodiments, but should be defined only in accordance with the 
following claims and their equivalents. 

15 
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